[Zope3-dev] Re: adaptation based on class rather than interface

[Jean-Marc Orliaguet]

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).
>
> Martin
>

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.

/JM