[Grok-dev] Re: Grok nomenclature

Brandon Craig Rhodes brandon at rhodesmill.org
Fri May 2 12:17:17 EDT 2008


Martijn Faassen <faassen at startifact.com> writes:

> Brandon Craig Rhodes wrote:

>> 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.
>
> Was it Philipp's idea? :) (Leonardo and myself brought it up I think)

You're correct!  Philippp and I were talking about things like
directives for signalling what gets grokked and what doesn't, and you
were indeed the one who jumped in with the idea of a marker interface
rather than a directive:

   http://mail.zope.org/pipermail/grok-dev/2008-April/004424.html

>>  +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.
>
> +1 to this.

Actually, there's a possible reason for us to -1 this: a directive
saying "grok this" will do its thing at grokking time, then get out of
the way and not affect runtime at all (I think?).  But an interface
sticks around for the whole dratted time that the program runs -
information from the grokking stage, in other words, will become a
permanent marker on the object itself.  Which means that, by
definition, one will not be able to grok an object so that it looks
*exactly* like the same object done up with ZCML, because there will
be at least the difference of the additional IGrokContext interface.

The other difference I can think of between a directive and an
interface for this job is that the interface gets inherited by all
subclasses of an object, and I'm not sure they can even avoid
inheriting it if they wanted to; so all subclasses would be doomed to
being grokked even if someone wanted to create a subclass that needed
special treatment with ZCML?  Whereas a directive has the opposite
problem: it applies, if I recall correctly how it was going to work,
only to the one exact class that includes the directive, and *not* to
subclasses, even if they wanted it?

Hrm.  Once again we seem to be moving in the direction of having lots
of different ways of doing the same thing.

-- 
Brandon Craig Rhodes   brandon at rhodesmill.org   http://rhodesmill.org/brandon


More information about the Grok-dev mailing list