[Zope-dev] implementing zope.component 4.0

[Charlie Clark]

Am 28.11.2009, 16:55 Uhr, schrieb Lennart Regebro <regebro at gmail.com>:

> That's what adapters are. They aren't reduced to it, it's what they
> do. They adapt one object with one interface to have another
> interface. That can indeed be seen as a type conversion.

I agree that that is probably the most common use for them.

>> Thanks for the comparison but it is semantically so different and
>> interfaces can be used for things other than adapters that I disagree.
> Yes but adapters can only be used as adapters, and the topic was the
> syntax for adapting an object.

My point is you can't necessarily tell much from the interface name.

>> The
>> most common example I know of the syntax is with INameChooser() which
>> brings us back to the differences (real or imaginary) between utilities
>> and adapters.
> I agree that calling an interface like that is a strange thing to do.
> I don't know what that would do, even. I have however never ever seen
> that done.

It's utility for avoid name conflicts when adding a new object to a  
container:

 from zope.container.interfaces import INameChooser
name = INameChooser(container).chooseName(obj.getId(), obj)

>> It's quite likely that I'm wrong in this but I see great potential using
>> adapters for delegation rather than straight conversion.
> But the delegation is adaptation. There is no difference.

For me, conceptually, there is quite a difference. An adapter is closely  
coupled to the object it is adapting. The common example is the headphone  
jack - electric impulses in and out. Delegation, at least the way I think  
of it, places the emphasis on separating the functionality, ie.  
decoupling, of the adapter from the object being adapted, even though  
technically it's exactly the same. I think of adapters as the gadgets that  
James Bond gets given by "Q" - it helps me get away from thinking about  
implementation.

>> I have very much
>> come to appreciate the power of this delegation in, say, BrowserViews;
>> even if it did take me several months to understand the multiadapter
>> pattern!

> I hear this a lot, so this is apparently something that is common to
> take a while to grasp. Any ideas of what to make multi-adapters more
> understandable would probably be a good thing.

hm, good question. With BrowserViews I think the problem is possibly with  
the whole idea of the REQUEST object which it's easy to oversee and just  
treat like a dictionary or storage. I normally concentrate on emphasising  
that the view has been delegated presentational responsibility by the  
content object in a particular context (maybe it is easier to understand  
adapting the content object and the request for a piece of HTML or PDF,  
etc.). Would it be too far fetched to imagine an engine adapting a car and  
petrol to provide motion?

Charlie
-- 
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226