Am 28.11.2009, 16:55 Uhr, schrieb Lennart Regebro <regebro@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