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. Chris
_______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev