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.
> class FootInFace(object):
> def __init__(self, foot, face)
> self.foot = foot
> self.face = face
> 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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -