On Mon, 2011-03-21 at 15:53 +0100, Lennart Regebro wrote:
On Mon, Mar 21, 2011 at 15:28, Jim Fulton <jim@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