At 11:48 AM 7/23/2007 +1200, Greg Ewing wrote: >Phillip J. Eby wrote: > > You seem to be saying that the ability to put things in different places > > encourages disorganization. > >No. What I'm saying is that there are conflicting organisational >requirements here. > >If the things being put in different places were independent >and able to be reasoned about in isolation, everything would >be fine.
And that is in fact the *normal* case, even in GF use. You seem to be arguing that possible == probable, when it simply ain't so. > But they're not independent, because different >overloadings of the same GF can interact, sometimes in >subtle ways, and reasoning about their interactions is >facilitated by being able to see all the relevant rules >together. Yeah, and a program *can* be full of monkeypatching and change classes' __bases__ at runtime, but most people don't write their code that way, most of the time. The whole point of GF's is that they make things *simpler*, because you can usually avoid the sort of awkwardness that accompanies trying to do those things *without* GF's. (E.g. adapters, registries, and the like -- which are just as hard to analyze statically.) Consider, too, that merely combining super() with multiple inheritance can produce very surprising results in today's Python. You cannot statically predict what method super() is going to call by looking at the code of the class that calls it. (Because a subclass can effectively insert bases between the class and its explicit bases.) In other words, if you want to know what's going on in a Python program today with regard to today's method combination next_method() feature (which we call super()), you already have to grep for *all* the method definitions. And this little bit of extra complexity doesn't even have a method combination decorator to call out that subtlety to you; you have to look in the method *body*. Even next_method has to at least be listed in the argument list. :) >Even if the rules don't, in fact, interact, it can be hard >to convince yourself of this without being sure that you >simultaneously know what all the rules are at some point >in time. Well, as I said before, you can always run the program and dump out the entire list, complete with filenames and line numbers if you're so inclined. That's certainly what I'd do, were I investigating some code I was unfamiliar with. And fancier tools could certainly be created, if they were needed. Python already has each and every one of the things you're complaining about, as binary operators depend on multiple argument values (and you have to know *both* types in order to work out the result), the method being called by super() can't be statically predicted any more than next_method(), can, and you already have to use grep if you're going after global understanding of a large program. If anything, generic functions give you *better* tools to work with, as there is no trivial way to fire up a program and say, "show me all the classes that have a foo() method." (You could probably write something to find them using object.__subclasses__, though, at least for new-style types.) _______________________________________________ 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
