On 7/26/07, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote: > On 7/23/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > For example, one pattern that sometimes comes up in writing methods > > is that you have a base class that always wants to do something > > *after* the subclass version of the method is called. To implement > > that without method combination, you have to split the method into > > two parts, one of which gets called by the other, and then tell > > everybody writing subclasses to only override the second method. > > > > With method combination and a generic function, you simply declare an > > @after method for the base type, and it'll get called after the > > normal methods for any subclasses. > > I've totally wanted to do that, so your email gave me a surge of hope, > but I think the generic function approach is actually worse here > (unless I'm totally misunderstanding). I think this would look like: > > class MyBase: > @generic > def mymethod(self): > default_stuff(self) > @after(mymethod) > def later(self): > more_stuff(self) > > class MyDerived(MyBase): > mymethod = MyBase.mymethod > @overload > def mymethod(self): > other_stuff(self) > > And if MyDerived just overrides mymethod normally, it replaces the > @after part too. > > So instead of telling people to override this other method (with the > benefit that immigrants from other languages are already used to this > inconvenience), you have to tell them to stick two extra lines in > front of their overrides. If they forget, the penalty is the same. > What's the benefit from generic functions here?
The more I think about this example (and the one in the PEP from which it's derived), the more I think this part is a frontal collision between two paradigms, and needs a lot more thought put into it. The need to say "mymethod = MyBase.mymethod" in the subclass, and the subtle disasters that happen if this is forgotten, and the rules that guide what code is called in what order when a subclass method is called with a type signature for which a better match exists in the base class, not to mention the combination of super() with next_method, all make me think that ths part of the PEP is not ready for public consumption just yet. Basic GFs, great. Before/after/around, good. Other method combinations, fine. But GFs in classes and subclassing? Not until we have a much better design. -- --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
