[Zope-dev] Interfaces vs ZCA concepts

[Leonardo Rochael Almeida]

Funny you should mention this, I've got this idea bugging for a few
weeks now, after the last thread:

Have the zope.interface package expose a single overridable hook:

def getInterfaceAttribute(iface, name, default):

This method would be called by any attempt to look up an interface
attribute that isn't provided by zope.interface itself. For example:

  IFoo.adapter(bar, default=baz)

  Would be the almost the same as:

  getInterfaceAttribute(IFoo, 'adapter', default=somemarker)(bar, default=baz)

That is unless getInterfaceAttribute(IFoo, 'adapter') returned the
passed-in marker which would instruct zope.interface to raise an
AttributeError instead.

In turn, "zope.component" could then provide a getInterfaceAttribute()
implementation that called:

  getAdapter(IFoo, interface=IInterfaceMethod, name='adapter')

Yes, the first parameter above is the original interface. The
IInterfaceMethod is an interface defining __call__(*args, **kw)

This idea would also allow one to define named adapters for
IInterfaceMethod to, for instance, "__call__" or "__add__", such that
the semantics of "IFoo(...)" or "IFoo + IBar" could also be changed.

Perhaps entry points could be used to provide getInterfaceAttribute
implementations, and if multiple entry points are present, each would
be called in turn to attempt to provide the attributes of an
interface, but maybe this is too much flexibility...

Just an idea...

Cheers, Leo

On Tue, Dec 15, 2009 at 14:16, Thomas Lotze <tl at gocept.com> wrote:
> So we've decided to let interfaces grow `adapt` and `utility` methods. I've
> written a simple and straight-forward implementation of them (see the
> tlotze-component-API branches of zope.interface and zope.component) that is
> closely modelled on the exisiting `__call__`. In particular, the new methods
> use component hooks which are like adapter hooks but with a richer set of call
> parameters. There are a few tests for the new methods as well, so everything
> should be fine.
>
> Except that I don't like the implications now that I have actually written
> down the code. I'll describe the problem I see and then suggest an idea that I
> don't think we've been considering in the discussion two weeks ago:
>
> We're intentionally leaking the concept of utilities to zope.interface.
> Assuming we're entirely fine with this, we still need to decide how much of
> the particulars of the ZCA we want to bring along: named components, lookup
> contexts, the ComponentLookupError. My current implementation tries to
> introduce enough generic behaviour into the `adapt` and `utility` methods so
> that they don't cause too obvious (conceptual) dependencies of zope.interface
> on zope.component:
>
> * `adapt` and `utility` don't define particular optional arguments but pass
>  all keyword parameters except for `default` to the component hook which,
>  being implemented by zope.component, keeps the knowledge about named
>  adapters and lookup contexts within the latter package.
>
> * The hook invokes the `query*` functions to play nice with any other
>  component hooks and the interface methods raise a TypeError if all of them
>  fail to find a component.
>
> However, the generic behaviour gets in our way: the method signatures become
> useless and hooks lose the possibility of raising useful exceptions.
>
> I've tried some variations but as long as the `adapt` and `utility` methods
> are actually implemented by zope.interface, it will always come down to a
> compromise that either renders the new methods unusable with anything that's
> not very much like zope.component, or makes for a half-hearted copy of the
> functionality we currently have in the zope.component API.
>
> I discussed this a bit with Wolfgang as we both don't like this kind of
> compromise in such core functionality. We came up with the idea that a clean
> solution would be to keep any implementation of the two methods out of
> zope.interface and rather inject them into the interface API by code kept
> entirely within zope.component. We do realise how close to the concept of
> monkey-patching this comes, but maybe it wouldn't be so bad if we could do it
> in a more structured way (being intentionally vague here yet).
>
> In particular, keeping the concrete `adapt` and `utility` methods out of the
> core implementation of interfaces would address the concern raised by somebody
> on this list that we were going to tailor zope.interface too much to the needs
> of the Zope ecosystem. Uses of interfaces other than adaptation and component
> lookup could get convenience methods registered by the same mechanism
> zope.component would end up employing, which is a big conceptual advantage
> from my point of view.
>
> What do people think of this?
>
> --
> Thomas
>
>
>
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev at zope.org
> https://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists -
>  https://mail.zope.org/mailman/listinfo/zope-announce
>  https://mail.zope.org/mailman/listinfo/zope )
>