[Zope-dev] Interfaces vs ZCA concepts

[Brian Sutherland]

On Tue, Dec 15, 2009 at 05:32:15PM -0500, Chris McDonough wrote:
> I wonder if maybe something like (notionally):
> 
> class InterfaceBase(object):
>      @classmethod
>      def add_more_api(cls, **kw):
>          cls.__dict__.update(kw)

I like this as a clear point to put a pdb when things do not go
according to plan.

> 
> 
> - C
> 
> Leonardo Rochael Almeida wrote:
> > 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 )
> >>
> > _______________________________________________
> > 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 )
> > 
> 
> _______________________________________________
> 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 )

-- 
Brian Sutherland