Re: [Zope3-dev] Re: adaptation based on class rather than interface
On 11/13/06, Jean-Marc Orliaguet [EMAIL PROTECTED] wrote: yes, but if you register an adapter for a base class you don't have to register it for subclasses, do you? I don't know, but again you then need to either subclass or re-register for that calss, but if you register it for an interface, you can eiterh subclass or implement the interface. subclasses will pick up the same adapter. Provided that you use classes for typing your objects and not interfaces. Class and interfaces do different kinds of typing. You do both, normally. I'm not sure the proliferication (?) of marker interfaces is a big risk. But if we get many of them, it still works better than the options of magic __something__ attributes. :) but conceptually it is the same mess :-) i.e. a total lack of specification. I don't agree with that at all. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.nuxeo.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adaptation based on class rather than interface
On 11/13/06, Jean-Marc Orliaguet [EMAIL PROTECTED] wrote: 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. Yes, and I think both you and me mentioned it, but with different wordings. If you specify it for a class, then only that class is adaptable. If you want to use the adapter for yet another class, you have to register it again. This is possible, but it's more flexible to specify the adapter for an interface, and let all adaptable classes implement that interface. This is also a matter of specifying things for what they can do, instead of for what they are, which you mentioned. I'm not sure the proliferication (?) of marker interfaces is a big risk. But if we get many of them, it still works better than the options of magic __something__ attributes. :) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.nuxeo.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adaptation based on class rather than interface
Lennart Regebro wrote: On 11/13/06, Jean-Marc Orliaguet [EMAIL PROTECTED] wrote: 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. Yes, and I think both you and me mentioned it, but with different wordings. If you specify it for a class, then only that class is adaptable. If you want to use the adapter for yet another class, you have to register it again. This is possible, but it's more flexible to specify the adapter for an interface, and let all adaptable classes implement that interface. yes, but if you register an adapter for a base class you don't have to register it for subclasses, do you? subclasses will pick up the same adapter. Provided that you use classes for typing your objects and not interfaces. otherwise I withdraw what I previously wrote (that classes were adaptable) if that's for individual classes only. The basic force behind adapter registration (based on interfaces) is the principle of inheritance. This is also a matter of specifying things for what they can do, instead of for what they are, which you mentioned. I'm not sure the proliferication (?) of marker interfaces is a big risk. But if we get many of them, it still works better than the options of magic __something__ attributes. :) but conceptually it is the same mess :-) i.e. a total lack of specification. It only looks nicer with interfaces. /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adaptation based on class rather than interface
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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com