[Zope-dev] implementing zope.component 4.0
charlie.clark at clark-consulting.eu
Sat Nov 28 11:35:01 EST 2009
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.
>> 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
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
>> 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
> 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?
Clark Consulting & Research
More information about the Zope-Dev