[Zope-dev] implementing zope.component 4.0

[Charlie Clark]

Am 28.11.2009, 16:06 Uhr, schrieb Martijn Faassen <faassen at startifact.com>:

>> I have to agree with this. IFoo(myobject) is not intuitive. I know it  
>> used
>> a lot because it's convenient shorthand but I've never read anywhere  
>> that
>> interface classes are, in fact, callables. We certainly don't normally
>> treat them as such.

Hi Maartijn,

> It's quite intuitive to me..
> Compare it with plain python:
>   >>> int(something)
> or:
>   >>> str(something)
>    >>> len(something)

> You say "give me something that's an int for the argument", or "give me
> something that's a string for the argument". You don't care how it
> accomplishes it, as long as it gives the right value back.



> It's even like adapters in the following way:
>   >>> int(1)
> Gives back the object itself, as it already is an int.
>   >>> int('1')
>    >>> int(1.5)
> Int is also "registered for" strings and floats, but essential different
> styles of "adaptation" happen there.

So adapters are reduced to type conversion?

> Calling an interface is really very similar to this.
> The main difference is that we don't use the concrete implementation's
> factory but that we use the interface that specifies the abstract
> behavior. That is a difference, but doesn't seem to be a huge step in my
> mind.

Thanks for the comparison but it is semantically so different and  
interfaces can be used for things other than adapters that I disagree. 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.

>> One of the things that I have grown to appreciate with the ZCA is the
>> advantage of spelling out the relationship between objects and I'll
>> happily take a little verbosity over magic.

> It's not verbosity versus magic. It's a better API versus a worse API.

>> The discussion does highlight a key source of confusion about Zope
>> interfaces: they are, at the same time, an object specification and a  
>> kind
>> of name tag or token that objects can provide upon request. While I know
>> that the second function is derived from the first it is conceptually
>> different.
>>
>> My preference, for the sake of clarity:
>>
>> adapted = an_easy_way_to_the_registry.adapt(*objects_to_be_adapted,
>> **identifiers)

> I'm not sure how this is supposed to work; what is identifiers?

That makes two of us! ;-) "identifiers" would be the key components -  
Interface/Tag (which is how I think of them in this context) and possibly  
name.

>> That adapters are all callable now seems to be an accepted convention,
>> presumably from convenience. But my understanding of adapters does not
>> imply this.

> I hope to have shown to you above that my understanding of adapters does.

It's quite likely that I'm wrong in this but I see great potential using  
adapters for delegation rather than straight conversion. 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!

Because I do, repeatedly, make simple mistakes with the adapter, utility  
(wrong name, wrong signature) stuff I very much appreciate attempts to  
simplify and clarify the API. But I will greet them the same poor grasp of  
the underlying concepts than I did the originals!

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