[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:
>> 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.


> 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. :)



More information about the Grok-dev mailing list