Guido wrote: >Does anybody know if Phillip Eby's generic functions support this?
Yes, and yes, they do. :) At least, the multiple-dispatch ones do. You can add a 'next_method' argument to the front of a method's arguments, and it's automatically passed the next applicable callable. (Which can also define next_method, and so on.) See: http://peak.telecommunity.com/DevCenter/CombiningResults#using-next-method > I >would think that the definition of "next candidate" can be problematic >there, in case you've broken a tie between two ambiguous possibilities >by registering an explicit tie-breaker. Remove the tie-breaker and >neither alternative dominates the other, so the next candidate is >undefined. Yes, but in that case you would want to use explicit upcalls anyway - the moral equivalent of doing BaseClass.foo(self,...) instead of super(Subclass,self).foo(...). There are also various ways to customize the way that methods are chained, too, which are described in the docs at: http://peak.telecommunity.com/DevCenter/CombiningResults >This is different from Python's MRO calculations, which >always create a perfect linearization of the base classes. Indeed. RuleDispatch's multiple-dispatch generic functions can't actually use the standard MRO for this reason. The single-dispatch API uses the MRO, but multiple dispatch uses a simpler algorithm that ignores the order of __bases__ for purposes of determining signature dominance. In other words, signature dominance is a graph or "partial ordering", rather than a linearization. > > BTW, another useful feature might be the ability to copy the protocol. > > Then I could register a few other adapters for the copy and use the > > modified copy for my own purpose. > >Let's not go wild with features; let's first collect use cases. Indeed. RuleDispatch's single-dispatch generic functions support cloning, as described in the VisitorRevisited article. However, I haven't used that feature as often as I thought I would, because it's really just a poor substitute for multiple dispatch. That is, the use cases that lead one to want to copy a protocol or single-dispatch generic function have usually turned out to be better served by rethinking in terms of a multiple-dispatch generic function. Also, you can achieve the same effect by chaining even single-dispatch generic functions, for example: @generic def g1(foo): pass @generic def g2(foo): return g1(foo) And you have now "copied" g1 to g2, simply by delegating the default case of g2 to g1. So, the motivation for the use case is sound, but in my experience, copying isn't really the best way to achieve it. Copying is IMO an artifact of "thinking in adaptation", or at least that's how I ended up thinking it was needed originally. _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
