[Grok-dev] Re: Grok nomenclature
Martijn Faassen
faassen at startifact.com
Fri May 2 05:03:41 EDT 2008
Martin Aspeli wrote:
> Martijn Faassen wrote:
[snip]
>> Actually I'd say it's not typically hidden away. It's signaled by a
>> directive (grok.grokked(), say), *or* by the base class being used in
>> the first place. There are also frequently other directives that can
>> signal you.
>
> I think grok.grokked() is an interesting pattern. That said, if there
> are two slightly overlapping ways (that, and/or a base class) then it
> may get confusing.
Agreed.
> Would you consider it a good idea to make it required or
> required-by-convention/ease-of-implementation for things not in the
> 'grok' namespace directly that use Grok techniques?
I'd say that 'grok.grokked()' could be used in packages in transition or
are strongly hybrid: you want to allow the same component to be
registered using ZCML or Grok techniques. I wouldn't see
'grok.grokked()' as required for packages which aren't in such a position.
I don't see any fundamental philosophical reason to want such a
signaling, just like I don't want such a signaling when ZCML is used, or
a meta-class is derived from, or a method being defined somewhere. That
there is a grokker that will register the class somewhere is not any
different from there being a meta class that might do the same thing
that you are inheriting from, or even some view that adds behavior to
its instances.
An explicit signal in my mind is only useful if there is an alternative
style of registration, and an original usage where registration happens
in some other way (ZCML) for the same class.
(if the ZCML starting point were not there, I'd argue we should
introduce a 'grok.ignore()' directive that tells Martian not to grok
this class at all, similar to 'grok.baseclass()')).
>> Compare with ZCML, where there is truly no information in the code
>> that this code will be registered by some file somewhere, perhaps even
>> 10 packages away. If you are in favor of conventions, why are you not
>> suggesting we prefix ZCML registered classes with a Z, say? :)
>
> I wasn't arguing for ZCML. ;-)
No, but why didn't I ever see you or anyone else make this argument? Did
I miss it? I'd say there's a stronger argument for conventions there
than there is here. :)
Regards,
Martijn
More information about the Grok-dev
mailing list