On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > > 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...). > > For methods you know what your bases classes are,
Not necessarily in the case of multiple inheritance; that's why Python 2.2 added super(). > but for adapters > that's not necessarily so. Somewhat could have registered another > adapter for the base class. > > Does anybody know if Phillip Eby's generic functions support this? > > If I understood Ian's posting > (http://mail.python.org/pipermail/python-3000/2006-April/000481.html) > correctly, they do. > > > 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. > > 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. -- --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
