On Monday 15 July 2002 06:06 am, Clark C . Evans wrote: ... > Although this is a nice question to ask; as a programmer with 10+ > years of building components, and using other's components to > build larger applications I often ask a similar but related question: > > Well, if it ain't a Thymagig, where is the > wrapper so I can treat it like one? > > It is this second question that the Object Adaptation PEP is based. Right. The concept of adaptation definitely comes from the Components world, where "is-A" is a dirty word. High time the Objects world listened:-). > Speaking of which, I personally don't feel that interfaces > is the way to go... there are many reasons why I'm using Python > and not using Java. Interfaces are too inflexible and often times > can cause more headaches than they save with additional typing. A suitably Pythonic approach to interfaces won't cause any more headaches than, say, booleans (check Google for the firestorm that the Booleans PEP caused...:-). We do need the CONCEPT of an interface, just as we need the concept of true and false values. Whether reifying the concept into a type or language-blessed category buys you more than it costs -- much depends on how it's done. Personally, I'd rather have that superset of "interface" that is known in Haskell as a "typeclass" -- and I'd settle for that middle ground that is known in C++ or Java as an "abstract class". If interfaces/typeclasses/&c came with Eiffelish 'contracts', so much the better. But it's all in the narrow range between -0 and +0 for me. > especially for Python. For example, interface inheritance is > one of those bits of baggage (that others may disagree with me on). > Interface inheritance is one of those "givens" that one must do to I'm not sure what you mean by "interface inheritance". The ability to define an interface by adding some stuff to another interface -- that's the only sense in which one could possibly speak of such a thing in Java, say -- is extremely convenient but not a must-do... COM manages without, not conveniently but OK all the same. I suspect you mean something quite different. > do interfaces right. Interface inheritance isn't needed. Why? > Mix-ins are far more powerful mechanism as they make you think about Mix-in inheritance is basically about _implementation_. Just like most inheritance in Python most of the time -- issubclass, isinstance and exception handling being the exceptions to the 'most'. Nobody's planning to take it away from Python, anyway. > operations which are othogonal to each other. You think that > interface inheritance helps, but in my experience it just screws > with your thought process... ;) I've had no particular trouble designing interfaces either in Java, with interfaces able to inherit from each other, or in COM, without such convenience. In the latter case one ends up with a bit of copy and paste, not pleasant, but WTH. I see it mostly as a bug in COM's MIDL and supporting tools/wizards -- they let you ask for interface inheritance even though the underlying object model does not support it (by doing the copy-and-paste implicitly) but then don't go all the way (e.g., they'll freely and erroneously reuse in the inheriting interface some method dispatch-IDs that the interface inherited-from has already assigned -- eccch). The big question is rather: given that Isub inherits from Isuper, does any object implementing Isub also implicitly implement Isuper? That's the object-philosophy, where inheritance is thought to reflect deep IS-A relations. It's NOT the component-philosophy, where inheritance is an implementation-convenience detail. I much prefer the component-approach, where my component has full control, if it wants to, on exactly what interfaces it exposes. This lets you factor out any commonality between interfaces without giving any actual reality to the factored-out common subset -- it can even stay an "abstract interface" that no object actually supplies, if you want. I do think it's a respectable thesis, though I don't agree with it, that the OO rather than component approach to inheritance is, while less flexible for advanced uses, easier to use -- made simpler by conflating different concerns (how is this interface exactly -- what set of interfaces can I get from this object) into one powerful general concept. I think it's harder when you have to learn that said "one powerful general concept" has several rather separate uses, and the ability to have some specific uses fall in the gray zone between the typical use cases does not exactly help learning and understanding, either. But I do think that quite a reasonable debate could be held about this. > Anyway, I'm so glad that Alex has taken up the cause; I'm not all > that actively involved in Python internals... but as a user I can't > advocate more for something like this. Alex, I'm delighted if > you would take ownership of the PEP. OK, thanks! 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