[Zope-dev] implementing zope.component 4.0

[Matthias Lehmann]

Am Montag 30 November 2009 16:57:11 schrieb Gary Poster:

> As above, I disagree.
> 
> As a matter of mechanics, when you register something we call an adapter,
>  it is a callable that takes one or more arguments.  If we were going to
>  follow the pattern that Marius laid out to establish what happens when,
>  then we have this, roughly:
> 
> register callable that takes two arguments:
> IFoo(bar, baz)
> 
> register callable that takes one argument:
> IFoo(bar)
> 
> register callable that takes no arguments:
> IFoo()
> 
> If instead we have the last step as what is proposed here
> 
> register non-callable
> IFoo()
> 
> then I think that breaks an important pattern for usage understandability.
> 
> That is, IFoo() can have a semantic if that is valuable, but it is not the
>  same as registering and getting non-called singletons.
> 
> Two by-the-ways:
> 
> 1) The term "adapter" is a barrier to understandability, in my interviews. 
>  This is particularly the case when people are introduced to the idea of
>  "multiadapter" and "supscription adapter".  In what ways are these
>  anything like a type cast?  IMO, they are not.  Our usage of adapter is as
>  a factory.  Yes, it can be used in other ways--so can a Python class--but
>  that is the essence of how our community uses this technology.  Calling
>  all these ideas "adapters" accomplishes nothing.  Explaining all of the
>  ideas as "a factory to produce an object that provides the interface"
>  cleanly describes our usage, and both "adapters" and "multiadapters".
> 
> (To be complete, I am in favor of ditching "subscription adapters" in favor
>  of other mechanisms related to named singleton lookups.)
> 
> One reason I like the syntax proposals for the adapter change is that they
>  treat the interfaces as pluggable factories.  This is apt.
> 
> 2) The term "utility" is another barrier to understandability.  They are
>  singletons.  Explaining them as such is a "well, why didn't you say so"
>  experience.
> 
> Therefore, I am in favor of removing the necessity to use the word utility.
>   That said, they are not factories.  They should not be mixed with the
>  two.  My preference for future changes is to have an API using the
>  ``singleton`` name.  Moreover, I think that some of the use cases that
>  Marius referred to for underpowered "utilities" coud be remedied by having
>  a utility/singleton lookup that allowed looking up by required values like
>  the adapter/factory lookup.
> 

I understand that most of us find

 IFoo(x, y)

looks just beautiful ... and I agree. But the question is, whether that beauty 
is worth the hassle of the backwards incompatibility and the proposed 
transition-strategies over the course of *many* years. That's a lot of 
complication, just to buy some beauty.

IFoo is an interface and an interface is at it's core a specification. Lot's of 
things can be done with this specification: validation, documentation, 
inspection ... and also lookup and adaptation.

For us, adaptation and lookup are the most important uses, but it's not in the 
very nature of an interface and somebody without zope-knowledge does not 
neccessarly have that same world view. So it may be convenient to make 
interfaces callable and return adapters/utilitys and it sure looks nice and 
requires little typing and all that - but in fact it's a quite zope-ish world 
view.

Wasn't it the main motivation to get rid of the need to having to import and 
use zope.component whenever we use multi-adaptation or utilitys?
So what's so bad about adding methods to interfaces? That meets the original 
motivation. And it leaves the interface as it's core as a specification and it 
makes it more clear, what the code does with the interface, instead of 
imposing our "adapters and utilities are the most important thing about 
interfaces" attitude onto it.

Also, it doesn't mix adapters and utilities conceptually. There is one method 
to get me a new instance for the interface and the given parameters and 
another method to get me some singleton/utility.

IFoo.instance(x, y)
IFoo.instance(x)
IFoo.instance()

or with less typing 

IFoo.new(x, y) ...

and

IFoo.utility() or IFoo.get() or IFoo.single() ... or some other color ...

Maybe we want another method, to return the factory without automatically 
calling it:

IFoo.factory(x, y) 
...

So we could deprecate the interface-calling functionality and just leave it as 
it is - this way we do not have to worry about year long transitions and 
confusion everywhere. 

This is also in line with IFoo.isProvidedBy(x) and the like.

OK - just a few thougths from an observer and zope-user.

Regards,

Matthias