[Grok-dev] Re: Grok nomenclature
Brandon Craig Rhodes
brandon at rhodesmill.org
Fri May 2 08:08:41 EDT 2008
Martijn Faassen <faassen at startifact.com> writes:
> 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
I still like "grok.me()". :-) Not only is "grok.grokked()" a bit ugly,
but since it puts the word "grokked" in the past tense, it sounds like
something that's already happened, not that you *want* to happen.
Plus, it clashes with the tenses of all of our other directives; we
don't, after all, write "grok.named('foo')".
Anyway, the main thing I wanted to bring into this discussion is a
reminder of Philipp's idea a few weeks ago that we signal grokability
with an interface. If I recall, he objected to the design of the new
package "grokcore.component" and how it includes a "Context" class
from which grokable classes like Model and Container can then inherit.
He correctly pointed out that forcing people to add yet another class
to their inheritance chain, not to add functionality, but just to
signal some property of the class, is wasteful and goes against the
whole design of Zope, which is to use interfaces where most other
people would use hordes of useless base classes. So he suggested
something like an "IGrokable" interface that Model and Container could
declare, which would take the whole issue of signaling to Grok out of
the inheritance hierarchy altogether.
In which case, given this current discussion, we would have *three*
ways of signalling that a class should be grokked:
1. Inherit from Model or Container or something else that's already
2. Start your class with "implements(IGrokable)".
3. Start your class with "grok.me()" (or, okay, "grok.grokked()").
+1 to Martijn's suggestion that only packages in weird situations
should ever need to use explicit markup about what gets grok;
we should avoid this practice ever becoming common
+1 to Philipp's suggestion that we try shifting grokcore.component
to using an interface rather than inheritance for grokability
+1 to the idea of throwing out the proposal for a *directive* that
signals grokking, and instead tell people in that edge/hybrid
situation that they should use Philipp's interface instead to
tell Grok what to pay attention to.
Brandon Craig Rhodes brandon at rhodesmill.org http://rhodesmill.org/brandon
More information about the Grok-dev