Multiple dispatch again
pedronis at bluewin.ch
Fri Jan 3 21:42:23 CET 2003
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:
> ...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()
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:
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
but it is rarely used (see the vacuum argument), e.g. Free CLIM codebase
does not use it.
More information about the Python-list