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

[Jean-Marc Orliaguet]

Philipp von Weitershausen wrote:
> Jean-Marc Orliaguet wrote:
>> Lennart Regebro wrote:
>>> On 11/9/06, Chris Withers <chris at simplistix.co.uk> wrote:
>>>> Why do you say "extra" ZCML registration? You need that ZCML
>>>> registration whether or not you have to write the marker interface...
>>>
>>> Sure, but with the marker interface you need only one. You need one
>>> for each class, in your example, thats two. So the second one is
>>> "extra". :)
>>
>> I think it is a mistake to use interfaces to specify what object 
>> _are_ as opposed to what they can _do_. It is better to use base 
>> classes for that. I agree with Chris that making classes adaptable 
>> would be simpler.
>
> Classes *are* adaptable as has been said many times already. Let's 
> please not make it sound like it's not possible.

Indeed technically yes. Practically not. I couldn't find many examples 
in the zope3 codebase that adapts classes.
The #1 pattern is to adapt from interfaces, it appears as though there 
is a reason for it.

So the best way to not make it sound so, is to use it so :-)


>
>> Interfaces were designed to specify what an object can do, e.g. a 
>> media player will do: play(), stop(), rewind(), without specifying 
>> the actual implementation ... whereas classes tell what objects are 
>> (an mp3 player, an LP player, a cassette player, ...), they are more 
>> specific to the object.
>
> More generally, interfaces were designed to specify the *behaviour* of 
> an object. Three basic types of behaviour have been identified in Zope:
>
> * perform an action (method API)
>
> * storing data (schema)
>
> * assumed behaviour that can't be expressed in an API or schema 
> (persistable, attribute annotatable, etc.)
>
> The last use case is the one marker interfaces serve. A marker 
> interface isn't any less of an interface. It just describes a 
> different category of behaviour, one that can't be expressed through 
> method or attribute APIs. It's still behaviour that we would like to 
> express formally, and using interfaces for that seems the most logical 
> solution.
>
> Interface docstrings are as much part of the formal interface as 
> method or attribute specifications! (Otherwise an interface could 
> never mandate the type of an argument passed to a method, e.g. 
> IContainer.__setitem__ only takes unicode or string names.)

yes, I agree. A perfect use case for interfaces without methods is when 
the specification cannot be expressed in a programmatic way. For 
instance persistable, etc. in that case only a natural language is 
appropriate.


FYI, the same discussion has occurred in Java (since there are marker 
interfaces there too and since there are interfaces too and the language 
does not prohibit using interfaces without methods). Are they an 
anti-pattern? An answer which I find perfectly valid is given at:

http://www.artima.com/intv/issuesP.html
under "Appropriate Use of Marker Interfaces"

however my reaction was against using interfaces without specification 
or interfaces with a very implicit and blurry specification, as in the 
cases described by Martin, in which he defends the use of marker 
interfaces basically as a way to tag classes "externally" (on/off 
switch, ...). A class annotation API would be better in that case, maybe 
based on the same internals as the interface API.

>
>> "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).
>
> That's always a problem with interfaces. Whether or not an interface 
> had specifications before or not, when you change an interface by 
> adding a spec, you will *always* have to track down all 
> implementations. That's why changing an existing, public interface 
> isn't such a good idea. This argument has nothing to do with marker 
> interfaces, though. It's a general problem of public interfaces.
>

yes, with the difference that marker interfaces have so little 
specification that they are almost meant to see their specification 
increase. That's what happened with all the magic flags and meta-tags in 
Zope2/CMF (isPrincipiaFolderish, meta_type, portal_type, ...). Using 
interfaces in that case does not solve the problem, and only shifts the 
problem to another area of the system.

as said in the article mentioned above, the same applies here:

[QUOTE] If the object you pass in has this marker interface, I will 
treat it in the following way. But I think that down that path lies 
darkness. Nobody knows the behavior of objects when they get their 17th 
marker interface. What if the object implements this marker interface 
and not this one, or this one and that one but not that other one? .
[END QUOTE]

>
> All that said, I don't think we should overdo marker interfaces (like 
> any kind of interface). I'm just saying they're not evil and it's not 
> like they violate the "pure truth" of interfaces. The third category 
> of behaviour may be unique to Zope interfaces, but that doesn't 
> necessarily mean it's a perverted use of interfaces.
>
>

they're not evil as long as you know what they are used for, and you 
don't abuse them.

regards

/JM