[Zope3-dev] Re: adaptation based on class rather than interface
Philipp von Weitershausen
philipp at weitershausen.de
Mon Nov 13 05:49:36 EST 2006
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.
> 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.)
> "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.
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.
--
http://worldcookery.com -- Professional Zope documentation and training
More information about the Zope3-dev
mailing list