[Grok-dev] Re: Grok nomenclature

[Martin Aspeli]

Martijn Faassen wrote:
> Martin Aspeli wrote:
> [snip]
>>> I realize that using conventions is more attractive if you are 
>>> evolving code forward that doesn't use Grok yet. That said, I still 
>>> hope for an end result of the evolution where there is a package which 
>>> just has classes, and that knowledge of whether it needs to 
>>> auto-register is actually not very relevant to the programmer. It's an 
>>> implementation detail, just like whether a meta-class is in use should 
>>> be an implementation detail (where, as you'll note, no conventions are 
>>> in use to mark them out either).
>> Mmm... I'm not sure that's a desirable end goal if taken to extremes. 
>> Yes, it makes sense for some primitives (like views, say), but if I 
>> suddenly get a lot of new behaviour by subclassing something, and that 
>> fact is hidden away from me, it'd be hard to debug and understand.
> 
> 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?

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

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book