On 2005 Jan 12, at 16:12, Phillip J. Eby wrote:
At 02:27 PM 1/12/05 +0000, Mark Russell wrote:I strongly prefer *not* to have A->B and B->C automatically used to construct A->C. Explicit is better than implicit, if in doubt don't guess, etc etc.
So I'd support:
- As a first cut, no automatic transitive adaptation
- Later, and only if experience shows there's a need for it,
Well, by the experience of the people who use it, there is a need, so it's already "later". :) And at least my experience *also* shows that transitive interface inheritance with adaptation is much easier to accidentally screw up than transitive adapter composition -- despite the fact that nobody objects to the former.
A-hem -- I *grumble* about the former (and more generally the fact that inheritance is taken as so deucedly *committal*:-). If it doesn't really count as a "complaint" it's only because I doubt I can do anything about it and I don't like tilting at windmills. But, I _DO_ remember Microsoft's COM, with inheritance of interface *NOT* implying anything whatsoever (except the fact that the inheriting one has all the methods of the inherited one with the same signature, w/o having to copy and paste, plus of course you can add more) -- I remember that idea with fondness, as I do many other features of a components-system that, while definitely not without defects, was in many respects a definite improvement over the same respects in its successors.
The other thing that really blows my mind is that the people who object to the idea don't get that transitive interface inheritance can produce the exact same problem, and it's more likely to happen in actual *practice*, than it is in theory.
Believe me, I'm perfectly glad to believe that [a] implied transitivity in any form, and [b] hypercommittal inheritance, cause HUGE lots of problems; and to take your word that the combination is PARTICULARLY bug-prone in practice. It's just that I doubt I can do anything much to help the world avoid that particular blight.
As for the issue of what should and shouldn't exist in Python, it doesn't really matter; PEP 246 doesn't (and can't!) *prohibit* transitive adaptation. However, I do strongly object to the spreading of theoretical FUD about a practical, useful technique, much as I would object to people saying that "using significant whitespace is braindead" who had never tried actually using Python. The theoretical problems with transitive adapter composition are in my experience just as rare as whitespace-eating nanoviruses from outer space.
Well, I'm not going to start real-life work on a big and complicated system (the kind where such problems would emerge) relying on a technique I'm already dubious about, if I have any say in the matter, so of course I'm unlikely to gain much real-life experience -- I'm quite content, unless somebody should be willing to pay me adequately for my work yet choose to ignore my advice in the matter;-), to rely on imperfect analogies with other experiences based on other kinds of unwanted and unwarranted but uncontrollable and unstoppable applications of transitivity by underlying systems and frameworks.
I already know -- you told us so -- that if I had transitivity as you wish it (uncontrollable, unstoppable, always-on) I could not any more write and register a perfectly reasonable adapter which fills in with a NULL an optional field in the adapted-to interface, without facing undetected degradation of information quality by that adapter being invisibly, uncontrollably chained up with another -- no error message, no nothing, no way to stop this -- just because a direct adapter wasn't correctly written and registered. Just this "detail", for me, is reason enough to avoid using any framework that imposes such noncontrollable transitivity, if I possibly can.
Alex
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
