Martin Aspeli wrote:
Jean-Marc Orliaguet wrote:

And there is nothing wrong with using inheritance when there is a '__IS A __' type of relation (e.g. an ordered folder IS A folder IS AN item, ...), or if there is a HAS_A type of relation (a folder has items, a chair has four legs...). It seems that Zope3 has banned all form of class inheritance, even those that made sense, and that would have simplified the implementation.

That is totally, utterly, patently rubbish. Devise some regular expression and grep the zope 3 source code for inheritance.

I was just expressing an opinion :-)  let me explain then:

subclassing is not used in zope3 as a method for assembling components, as it was used in zope2. In zope2, if you mix a folder with a catalog aware mixin, you'd have a catalog-aware folder because the functionality is expressed in the mixin class, not outside. In zope3 if you subclass a container you still have a container, it won't make the container more specialized. Now of course zope3 uses subclassing internally to avoid duplicating code. No need to devise a grep tool to know that.

"marker interfaces" have empty specifications, that's the problem: they can't grow into "real" interfaces that have a specification. If you add methods to the marker interface you will have to track down all classes that implement the interface (unless you don't really care whether classes do implement their interface).

Marker interfaces by design serve a different purpose than other interfaces. They are the equivalent of an on/off switch about object behaviour or purpose that is externalised from that object (i.e. they are not just booleans in a schema, they are potentially managed outside that class).


I don't think that marker interfaces were ever "designed", they are the result of pushing a design to its limits, without knowing what an interface is supposed to mean in the first place. That's what happens when implementation gets confused with design, and when one feels the need to unify everything. It would have been better to have a common API for accessing or registering meta-information about classes, this is what marker interfaces do in the end since in their *implementation* they are stored in a class attribute ('__implemented__'), but that implementation feature should not be exposed to the programmer through the 'interface' API. Otherwise the concepts don't mean anything anymore.

Zope3-dev mailing list

Reply via email to