

MultiMethods for Python - twampss
http://alexgaynor.net/2010/jun/26/multimethods-python/

======
gometro33
The difference between this and true overloaded methods (which, correct me if
I'm wrong, is the what he meant by "MultiMethod") is that an overloaded method
is created at compile-time and does not incur the added cost of determining
the type of the object at runtime.

That being said, I didn't know that Python doesn't have function signatures.
Would someone care to comment on how a function is identified?

~~~
xi
Multi-methods are not overloaded functions (in the C++ sense). You are correct
that overloaded function calls are resolved at compile-time while multi-method
calls are resolved at runtime, but if you want to make a C++ analogy, you'd
better compare them to virtual methods. Multi-methods work almost like virtual
methods, with two exceptions:

1) multi-methods are declared outside the class definitions; it is important
since it allows you to extend a class without directly modifying its
definition or implementation.

2) virtual functions do dispatch by one argument (`this` in C++) while multi-
methods could perform dispatch by an arbitrary number of arguments.

That said, I don't like this implementation that much since it does not
respect class inheritance. Suppose you defined a MultiMethod with two
registered implementations, for class A and class B, where B is inherited from
A. Then the result of the multi-method call with an object of type B is
undefined. A proper multi-method would call the most specific implementation
in this case.

~~~
dkersten
In C++, methods are only dispatched by the _type_ of the arguments. In, for
example, Clojure's multimethods you can dispatch on pretty much anything: type
of some or all arguments, their values, function of either (or both)... etc.

Quick example:

    
    
        (defmulti foo #(* % 100))
        (defmethod foo 0 [_] "passed in zero")
        (defmethod foo 100 [_] "passed in one")
        (defmethod foo 200 [_] "passed in two")
        (defmethod foo :default [n] (str "passed in " n))
        ...
        >>> (foo 2)
        "passed in two"
        >>> (foo 5)
        "passed in 5"
    

(written off the top of my head, so excuse any mistakes..)

I'm only using a single argument here and I'm dispatching on a function of its
value. I could just as easily dispatch on multiple arguments (or an arbitrary
amount).

~~~
xi
I wonder how Clojure deals with ambiguities when dispatching by arbitrary
predicates. Also in this case, the overhead of of generic call will grow
linearly with the number of methods, right?

In Python, you could limit generic dispatch to argument type only without
losing generality since you could override the `isinstance` operator. For
instance, you could define a `const()` type so that `isinstance(x,
const(100))` is true if and only if `x == 100`. Then your example could be
written in Python as:

    
    
      foo = generic()
    
      foo.when(const(0))
      def foo_0(x): print "passed in zero"
      foo.when(const(100))
      def foo_100(x): print "passed in 100"
      foo.when(const(200))
      def foo_200(x): print "passed in 200"
      foo.when(int)
      def foo_default(x): print "passed in", x
    

This is not as elegant as in a language with native support for generic
functions, but it works. I wish mainstream languages started to adopt multi-
methods; it's conceptually very simple and much more extension-friendly than
traditional OOP. Sadly it doesn't seem to happen.

~~~
dkersten
_the overhead of of generic call will grow linearly with the number of
methods_

As far as I know, no. I could be wrong, but I think how it works is this: each
method is added to a map for that multimethod. When dispatching, the dispatch
function is applied to the arguments and the result is used as the key into
the map of methods. I'm pretty sure that the compiler could optimise the
lookup too, though I don't know if Clojure does or not.

Thats just what I would do if I wrote Clojure - I don't actually know how
Clojure manages it in real life (and am too lazy to check).

Yeah. I've always wished that languages like C++ had two things: multimethods
and ML-style pattern matching (well, three things - I guess you'd want ML-
style parametric types to go with the pattern matching).

------
deno
You shouldn't test for arguments with isinstance(). Better test for specific
functionality. It's like FreeBSD developers being angry that people use tests
like 'somecmd --version' in autoconf scripts and thus software not compiling
even though required functionality was available.

