On Tuesday 16 July 2002 01:46 am, Barry A. Warsaw wrote: > >>>>> "AM" == Alex Martelli <aleax@aleax.it> writes: > >> what Zope does AFAIK). Otherwise creating minor variations on > >> a class would be quite a pain -- you'd have to repeat all the > >> interfaces implemented by the base class; and what if a later > >> version of Super implements more interfaces? > > AM> This is actually a difficult point. If I have to explicitly > AM> state all the interfaces of Super that I want to _exclude_, > AM> and Super adds some more interfaces tomorrow, then it's quite > AM> possible that my class is suddenly broken -- it doesn't > AM> guarantee the invariants that says it guarantees, any more -- > AM> and I don't even know about it. > > You'd need a way to explicitly state that you implement /none/ of the > interfaces of your superclass, and then explicitly add back the ones > you do implement. Right -- "i inherit the implementation but none of the interfaces". You can express this either by appropriately tagging the "I inherit" part, as C++ does (private inheritance -- the default, but that's yet _another_ C++ issue... defaults that may or may not be appropriate for typical use!-), or with a variation of "exclude-interfaces" however you spell that. Alternatively, "I inherit" could default to "not the interfaces", and, if needed, one might add a clause "oh, and all the interfaces too, please" when that is positively desired. Maybe the default would best be chosen on the basis of "what is good for them" rather on "what appears most desirable intuitively", as is currently done for module imports. Defaulting to "i inherit all" is roughly as convenient as defaulting to "from amodule import *" would be felt to be by naive users unfamiliar with the issues of namespace pollution. You know, "convenience" is getting to be something of a dirty word:-). Knuth said "premature optimization is the root of all evil in programming", and no doubt he was right for HIS generation -- people who grew up on machines with a few KB of memory and small fractions of MIPs were warped for life by the need to squeeze every possible drop of optimization. We still have some of that, no doubt. But current generations of programmers grew up on machines of overwhelming power -- gradually, the pitfall of premature optimization becomes less pervasive. OTOH, the same programmers grew up on machines overburdened to the gills with a surfeit of "convenient" features... a new "root of some evil" is emerging, and it's spelled "convenience". Perl's surfeit of ad-hoc, context-dependent, highly-"convenient" surprises just waiting to trip you at every step should be an object lesson in "convenience". Simple, clean, orthogonal, predictable, clear, unsurprising, regular. Now THESE are the buzzwords I long for... "convenient", OTOH, makes me wary. Convenience has its place, just as does optimization, and Python has traditionally done a great job of supplying just enough optimization and just enough convenience without compromising the really important buzzwords above listed. OTOH, the BDFL does say that he's not very experienced with "components" (interface-based programming); and few can claim extensive experience with many different nuances of that (on introspection, I _would_ claim for myself extensive experience with production use of COM, but a bit lesser with "bare C++" [a la Lakos, say] and definitely not "extensive" for Java, Haskell and others). Would we REALLY like to have: import foo do the equivalent of today's from foo import * and have to explicitly say import foo dont_pollute_my_namespace to get today's "import foo" behavior? I'm sure many beginners would love it -- you have to pound their heads with a mallet to wean them off the "import *" even today, particularly if they come from languages which offer the equivalent facility (e.g., C++'s "using namespace" -- back in think3, I got hoarse from having to repeat over and over again that making "using namespace std;" a standard prologue of every source file was NOT clever -- and I'm talking about able, mature programmers, quite used to large-scale programming in C++... but namespaces were new, and were perceived as "inconvenient"...!). Now, the amount of desirable separation between components may be lesser than the high separation that is most desirable between modules / namespaces -- but it IS higher than that most desirable between "ordinary" objects under inheritance. I surely don't know "the solution", but I just as surely do feel there ARE issues here that are worth pondering about. Just my two Eurocents (now worth slightly MORE than 2 cents of US$...!-) 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