Thomas Lotze wrote:
>> * We want to implement .adapter(), .utility() and .__call__() in
>> zope.component as much as possible.
> The method's name is `adapt`, JFTR.
Whoops, yes, I prefer 'adapt' actually anyway. :)
>> * we want a similar mechanism for each of them to plug in.
> Agreed, even though (AFAICT) we haven't been talking about moving the
> implementation of __call__ to zope.component so far.
I figured we'd want to treat each of them in the same way.
>> * 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.
> One thing I start questioning is an adapter registry being implemented by
> zope.interface. Moving it to zope.component seems to me to be related to
> keeping the implementations of the new method within zope.component.
I'm not sure where that stuff should be. I'll defer some of this to Gary
again, who is interested in working on this topic. :)
>> * 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
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.
>> Their behavior should be:
>> 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.
> In that sense, these stubs would be worse than
> zope.interface not documenting the methods at all.
I strongly disagree. We want to define a bunch of methods on Interface
that we want everybody to have access to. We can't then turn around and
say we really actually don't want to implement those methods on Interface.
That Interface *delegates* the implementation to something else is fine,
but the methods are conceptually on Interface, and delegation is
normally implemented by just calling the code we delegate to.
> In my and Wolfgang's opinion, we can either have zope.interface implement
> methods with the real contract, which would mean defining the full
> concepts of the ZCA within zope.interface (if not their implementation),
> or not even have method stubs in zope.interface and leave the whole
> business of defining specialised uses of interfaces to other packages such
> as zope.component.
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
>> What's the behavior of __call__ now if zope.component isn't around?
> Similar to what you've just described of your `adapt` method, up to the
> name of the `default` parameter and the exception raised.
So if no registry is available (zope.component not installed), you can
still call it and it'll just behave as if the registry is empty? That's
>> * Tres brought up that we can come up with a clean plugin interface
>> instead, and now I'm tempted to go for that instead of monkey-ing around.
> I'd have to think about that some more, but while reading it the first
> time, it feels quite wrong to me.
You'll have to go into more detail. Why does it feel wrong to you? It's
the way plugin APIs generally tend to work. You could even look up this
API as a utility - but that's probably a chicken and egg problem. :)
[see below for a possible improvement on this API]
>> I realize that the proposal for a plugin API gives zope.interface some
>> knowledge about adaption and utility lookups, which is what Thomas and
>> Wolfgang had trouble with. But after all that's what we're doing anyway by
>> putting those methods on the API, one way or another.
> No: the zope.interface package doesn't have any knowledge about the
> particulars of any of the uses of interfaces. One might claim that
> interfaces do after they've been patched by other code,
That's what I claim. :)
Why is it a problem that the zope.interface package gains knowledge
about adaptation (which it always had, anyway) and utility lookup?
Because to the user of those methods on Interface, it looks exactly like
the package does have such knowledge. We shouldn't lie.
> but then, that's
> after some application has made its choice about plugin certain packages
Generally when we have patterns like this we *do* explicitly define
plugin points on the thing we plug into. It's a lot more clear when
there's an explicit plugin API available.
> It's not baked into zope.interface, and that's what we're trying
> so hard to achieve.
But why are you trying so hard? What's the point of trying to do this?
>> [Philosophically from my own perspective I think we'd have much less
>> conceptual difficulty with this if we just made __call__ do all lookups,
>> as that hides the whole set of concepts of utility versus adapter a bit,
>> but we can't get consensus for that unfortunately. But I'm biding my
> Implementing __call__ within zope.interface in that way would get the
> package rid of the method names `adapt` and `utility`,
In my mind you do more than just getting rid of names if you just had a
multi-functional __call__. You introduce the following notion into
"please look up an object that provides this interface, somehow. (with
zero or more context objects)"
How that task is fulfilled, by adapters, utilities, null-adapters or
contextual utilities doesn't matter to zope.interface. That's up to
zope.component. To me putting those notions in zope.interface is a bit
of conceptual leakage we could have avoided, but we've already concluded
that discussion for now and we're going to go with 'adapt' and 'utility'.
> but the technical
> problem with the method signatures and the more philosophical one about
> whether zope.interface should really make adaptation stand out as a use of
> interfaces remains.
We've had this behavior for *years*. We're extending it with one new
concept, utility lookup (multi adaptation being an extension of the
> Which brings me back to the question I asked earlier, and which nobody has
> replied to so far:
I think by now I have. :)
> Do we want to make zope.interface completely unaware of
> any particular uses of interfaces, or do we want to treat component lookup
> and in particular the ZCA's way of looking up components as a special case?
Since zope.interface is already aware of particular uses of interfaces,
such as adapter lookup (and classes implementing interfaces, and so on),
I'd say it's all right if we teach zope.interface about looking up
utilities and multi adapters by interface too, in its own API.
Having thought about it, I think the right way to do this is by a
well-defined plugin point in zope.interface.
In fact, let me propose the following plugin point instead, reducing it
to a single method:
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
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.
[I am getting closer to my preferred API here, but it's only an
implementation detail, people.. nothing to see here! :)]
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -