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
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to