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