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

2006-11-14 Thread Lennart Regebro

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

2006-11-13 Thread Lennart Regebro

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

2006-11-13 Thread Jean-Marc Orliaguet

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

2006-11-11 Thread 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
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com