[Grok-dev] Re: Grok nomenclature

[Brandon Craig Rhodes]

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
> position.

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
   grokked.

2. Start your class with "implements(IGrokable)".

3. Start your class with "grok.me()" (or, okay, "grok.grokked()").

So:

 +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