On Thu, May 7, 2009 at 7:01 PM, Chris McDonough <chr...@plope.com> wrote:

> People are often confused about the duality of zope.interface Interface
> objects
> being used as markers during adaptation as well as being used as a
> mechanism to
> describe an API.  Personally, I think it should be possible to keep the two
> concepts logically distinct in any given application.  I don't really have
> a
> sense of how abstract base classes would fit in here.
> Yeah, my thinking has been, generally, that the fact that it's fairly
common for people to create interfaces purely to have a marker to use for
ZCA lookups, exposes a problem with the ZCA.  An interface that is not an
API specification is not really an interface.  So called marker interfaces,
to me, abuse the idea of an interface.  I find repoze.plugin intriguing, in
part, because it fixes this problem.  AFAICT, it does everything
zope.component does but adds some new use cases and makes the solutions to a
few others seem less abusive of certain basic concepts.

I don't have a lot of hope for its general adoption--it's awfully abstract
to be accepted outside of Zope circles and inside of Zope circles there's
already the ZCA, even if it seems a bit warty in places.  The Zopistas seem
to be the few folks, though, interested in such high levels of abstraction
and formalism.

Among the more obvious use cases, to me, is the case Zope/Plone programmers
run into all the time where they want to apply different components to
different branches of their object graph--ZCA just doesn't really handle
this at all, and yet it's very common to want to do this.  The canonical
solution is to apply marker interfaces to different objects in your graph in
order to game the adapter lookups, but that's awfully hacky and not very
satisfying at all.  I haven't sat down and pieced together how you'd do it
in repoze.plugin, but it seems to that the fact that you can really use
anything as a marker for your lookups, means you *ought* to be able to make
this work in a bit more intuitive way.

Repoze-dev mailing list

Reply via email to