[Zope-dev] implementing zope.component 4.0

[Lennart Regebro]

On Sat, Nov 28, 2009 at 17:35, Charlie Clark
<charlie.clark at clark-consulting.eu> wrote:
> 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.

No, that's what they are. An adapter is something that adapts one
interface to another. That's the definition of the adapter pattern.
It's not the most common usecase, thats THE usecase. If it doesn't do
that, it's not an adapter.

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

Of course.

>> 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)

Ah, OK. You skipped the container parameter. That's just an adapter.

>> 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.

Absolutely.

> 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.

Well, that's just a matter of creating the Interface with a specific
goal in mind.

You separate two types of adapters in your inner conceptualisation:

Case 1. I have an American Power port, but I need to put it into a
european one, so I get an adapter.

Case 2. I'm going to make a laptop power supply. I therefore design it
so that I can connect various adapters into the power supply, MacBook
adapter style.

In the first case I have two interfaces designed by others, and adapt
on to the other. In the second case, I design an interface
specifically so it will be easy to make adapters for it to the
different uses I envision.

But those cases are still just adapters. It's different situtions to
be in as a programmer, but technically they are exactly the same. It's
just adapters.

> I think of adapters as the gadgets that
> James Bond gets given by "Q" - it helps me get away from thinking about
> implementation.

I don't see how that works.

> 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?

Works for me.
-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64