On 4/5/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: > I'm hoping that Walter can give some more realistic examples since I > don't have real-world experience here. The basic idea is simply to let > an adapter give up and let the protocol try the next adapter. This could > happen in a generic function, for instance, if you wanted to try some > fast algorithm for some specific subtypes, but the algorithm might be > inappropriate depending on the values of the subtypes. You don't find > that out till your in the adapter itself.
Hm... The alternative, of course, instead of some magic feature, is to explicitly call the fallback algorithm. That seems totally reasonable for this example, and is similar to Python's single-inheritance-style explicit super-call e.g. return BaseClass.methodName(self, arguments...). Does anybody know if Phillip Eby's generic functions support this? 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. This is different from Python's MRO calculations, which always create a perfect linearization of the base classes. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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