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
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