On Mon, 2011-03-21 at 15:53 +0100, Lennart Regebro wrote: > On Mon, Mar 21, 2011 at 15:28, Jim Fulton <j...@zope.com> wrote: > > This might be OK for @implements and maybe @adapts, which describe > > behavior, but start feeling wonky to me for something like: @utility. > > Well, the wonkyness comes from @utility *not* being inherited, while > @implements would be. That could be confusing. > > It wold be possible to let @utility be inherited if it's done by > scanning, though. But under what name in that case? I think that > possibly would be even *more* confusing. > > It may be that decorators isn't the right answer for registration. In > that case scanning is an option, unless we simply go for straight > imperative configuration. > > @implementer(IMyFace) > @adapter(IMyFoot) > class FootInFace(object): > def __init__(self, foot, face) > self.foot = foot > self.face = face > > component.utility(FootInFace()) > > It's easy and clear, but has the drawback of encouraging that > registration is done on import time, while scanning separates the > registration from the definition. I'm not sure how important that is.
It's important to me, at least. Registration-on-import effectively requires that there only be a single component registry for all applications in a process. This is often fine for a given deployment, but as a framework strategy it seems very limiting. - C _______________________________________________ Zope-Dev maillist - Zope-Dev@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 )
