[Zope-dev] A summary of "Interfaces vs ZCA concepts"

[Thomas Lotze]

Hi,

this is a long message with a lot of replies to things that I don't agree
with. Since I realize that making those points over and over again doesn't
get us anywhere, I'd like to point out first that I'm going to implement
Martijn's suggestions anyway on one of my branches, hoping that seeing
more actual code to talk about might help getting to more consensus.

Martijn Faassen wrote:

>>> * It'd be nice if __call__ came back with a LookupError instead of a
>>> TypeError, but how to get from A to B without breakage?
>> 
>> It's not possible without breakage.
> 
> Unless we create a zope.interface specific LookupError which subclasses
> both the built-in LookupError and TypeError. zope.component's
> ComponentLookupError should subclass this special LookupError then.

Technically true, so my statement was admittedly too strong. I just don't
feel comfortable with the idea, which may well be just because it's the
"let's make both exceptions work sowmehow" solution to me instead of the
clear change I thought we were considering. OTOH, it's not that big an
issue either, so I guess I'd be fine with it.

>>> * the methods can be on zope.interface even if zope.component isn't
>>> installed. They will behave as if the component registry is empty.
>> 
>> This isn't covered by the consensus you mentioned above as far as I'm
>> concerned.
> 
> Yeah, I put that in so we can reach consensus on it. I thought Tres had a
> good idea going on there that makes the plugin behavior a lot cleaner.

Hm, I can't help feeling pushed into this. While this plugin stuff is
indeed nice *assuming* that we want all the zope.component concepts in
zope.interface, it doesn't contribute to the decision about *whether* we
want that in the first place.

>>> IFoo.adapt(context) raises LookupError, unless the context provides
>>> IFoo, in which case it returns context.
>>>
>>> IFoo.adapt(context, default=default) returns default unless context
>>> provides IFoo, in which case it returns context.
>>>
>>> IFoo.utility() raises LookupError.
>>
>> IFoo.utility(default=default) returns default
>> 
>> I think looking at that API explains why we have trouble with having
>> stub methods defined by zope.interface: these methods contain enough
>> information about component concepts to blur the distinction between
>> zope.interface and zope.component, but they still lie about the actual
>> method signature.
>
> I don't understand you: why do you say they lie about their method
> signature? They should have the same signature and have a well-defined
> behavior if zope.component is not installed: there is nothing registered
> at all. zope.interface provides a plugin point that allows one to plug
> lookup behavior into it.

When I wrote that, I was assuming that we were talking about patching
interfaces with methods that have zope.component's full lookup semantics,
including `name` and `context` parameters - which abviously would change
the signatures. If we're talking about something that doesn't add those
parameters, there's no lie involved but I don't see how our lookup methods
could then access the full feature set of zope.component's lookups.

> In that case, I want the real contract to be in zope.interface. That's
> where the methods are, after all. We need to talk about the concept of an
> adapter and a utility briefly in zope.interface and defer to
> zope.component as the most common implementation. We already have this
> kind of behavior going on anyway with __call__() (even though not
> documented!).

Well, we obviously disagree completely about this. The existing __call__
method is neither a good example of a zope.component lookup API, nor do I
think that it was fortunate to wire up the adaptation concept in
zope.interface through __call__ in the first place. I'd rather try to
loosen this reference to component concepts than use it as a reason for
adding more.

> You'll have to go into more detail. Why does it feel wrong to you?

Because it is just another way of encoding the zope.component details
within zope.interface. I would love to add a plugin API that is generic
enough to apply equally to other uses of interfaces than component lookup,
and that would allow implementations of component lookup with different
concepts and different lookup methods than those of zope.component.

> Why is it a problem that the zope.interface package gains knowledge about
> adaptation (which it always had, anyway)

(and which, IMO, it shouldn't have in the first place)

> and utility lookup?

Because if we're serious about making interfaces more of a language
feature, they should at their core be reduced to *being* mostly
information (maybe with a bit of verification code) instead of extended to
*doing* things that derive mainly from *our* particular ways of using them.

> Because to
> the user of those methods on Interface, it looks exactly like the
> packa
> does have such knowledge. We shouldn't lie.ge

I don't think that we lie as long as we state that we have a plugin system
of any kind (including monkey-patching, for the sake of discussion).
Speaking about lies again, I also consider it a kind of lie to say that we
provide a plugin system if it turns out in the end that it isn't much good
for anything but the one particular plugin provided by zope.component.

> In fact, let me propose the following plugin point instead, reducing it to
> a single method:
> 
> class ILookupPlugin(Interface):
>     def lookup(interface, contexts):
>          """Look up an object that provides interface, given contexts.
> 
>          contexts may be an empty list, or contain one or more entries.
> 
>          Raises LookupError if an object providing the interface cannot be
>          found.
>          """
> 
> Then __call__ and adapt and utility can be implemented by using
> "lookup()". Anything plugging into zope.interface would then have to only
> plug in a single method.

Would this in your mind still include a list of hooks whose behaviour
needs to be coordinated by the Interface methods (which affects at least
how exceptions are caught or propagated), or are we talking about a single
plugin being registered at a time? I'd prefer the latter as it's more
straight-forward. Or are there really compelling use cases for registering
more than one hook at the same time?

-- 
Thomas