Multiple dispatch again

[Samuele Pedroni]

From: "David Mertz" <mertz at gnosis.cx>
> The way I handle things in my current implementation (only propogating
> dispatch AT_END or AT_START) already includes generic guards to prevent
> non-existing less specific methods from being called.  With a user
> controlled multi_super(), you would need to add your own guards, and
> change the flow to account for contingencies:
>
>     def semi_specific(this, that):
>         ...do stuff...
>         try:    # maybe there is *some* less specific method
>             val = multi_super()
>         except NothingLessSpecificError:
>             try_to_fix_things()
>         ...more stuff...
>
> Calling super() doesn't run into this problem.  Now I -could- try to do
> something "safe" in multi_super() as a fallback.  A 'pass' is pretty
> safe from an execution perspective.  But if 'semi_specific()' wants a
> return value, there is no way a fallback can guess a usuable value.

Still I don't see what is the difference:

>>> class A(object): pass
...
>>> class B(A):
...  def method(self):
...    return super(B,self).method()
...
>>> B().method()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 3, in method
AttributeError: 'super' object has no attribute 'method'

It is just like single dispatch, one does not write methods in a vacuum, one
has some knowledge about what signatures are covered,
and about the hierarchies.

multi_super should probably have a signature like:

multi_super(multimethod,signature,args...)

or be a method-as-useal of Dispatcher (?).

And yes I could produce Lisp fragments (((....))) using call-next-method.
And indeed there's also next-method-p

http://www-2.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Body/locfun_next-
method-p.html

but it is rarely used (see the vacuum argument), e.g. Free CLIM codebase
does not use it.

regards.