From: "Greg Ewing" <greg@cosc.canterbury.ac.nz> > David Abrahams <dave@boost-consulting.com>: > > > This concern seems most un-pythonic to my eye, since there are already > > all kinds of ways any module can change the behavior of any call in > > another module. > > Yes, but most of the time you don't have to use them! > With this feature, it would be the *normal* way of using > it. I don't understand. You still don't have to use it. Nobody would force you to add or encourage multimethod overloads. In fact, I think it would be most appropriate if multimethods meant to be overloaded had to be declared explicitly. > > forcing all the definitions to be in one place prevents an important > > (you might even say the most important) use case: the author of a new > > type should be able to provide a a multimethod implementation > > corresponding to that type. > > You can get that without the notion of a generic function as a > separate entity. Just have a dispatch mechanism that looks in all the > arguments of a call for a method to use, instead of just the first > one. > > That would be relatively tractable, since at least you'd know that the > method must be found in one of the argument classes somewhere. Nooooo-o-o-o-o....! (Sorry, I'm overreacting... but just a little) That approach suffers from all the problems of Koenig lookup in C++. Namely, if I provide a method foo in my class, and two different modules are invoking "foo", whose idea of the "foo" semantics am I implementing? That really becomes a problem for authors of generic functions (the ones that call the multimethods) because every time they call a function it essentially reserves the name of that function for the semantics they're it to have. This is currently, IMO, one of the most-intractable problems in C++ and I'd hate to see Python go down that path.** If you want to see the gory details, ask me to send you my paper about it. > It also doesn't suffer from the who-imports-the-module problem, since > someone must have imported it in order to get an object of that class > in the first place. I don't think that's a serious problem. Multimethod definitions that apply to a given type will typically be supplied by the same module as the type. > The use case that this doesn't cover is where you're not defining a > new class, just trying to add behaviour to handle a previously > unanticipated combination of existing classes. The organisational > problems involved in that aren't unique to Python, and seem to me an > inherent feature of the problem itself. Where does functionality > belong that isn't owned by any class? Often there's behavior associated with combinations of classes from the same package or module. It's reasonable to supply that at module scope. Besides the practical problems mentioned above, I think it's unnatural to try to tie MULTImethod implementations to a single class. When you try to generalize that arrangement to two arguments, you end up with something like the __add__/__radd__ system, and generalizing it to three arguments is next to impossible. Where to supply multimethods that work for types defined in different modules/packages is an open question, but it's a question that applies to both the class-scope and module-scope approaches -Dave ** Python is very nice about using explicit qualification to associate semantics with implementation (i.e. we write self.foo(x) and not just foo(x)), and this would be a major break with that tradition. Explicit is better than implicit.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4