[Grok-dev] Re: Grok nomenclature
optilude at gmx.net
Fri May 2 03:51:36 EDT 2008
Martijn Faassen wrote:
> Martin Aspeli wrote:
>>> 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. ;-)
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
More information about the Grok-dev