[Grok-dev] overriding Grokkers
faassen at startifact.com
Tue Oct 16 09:23:41 EDT 2007
Fernando Correa brought the following use case for Martian to my attention:
* we have a grokker defined for some class inside Grok
* we want to define a subclass for this class
* we want there to be a grokker for this subclass
* we *don't* want the grokker for the base class to do any work
(I hope I got it correct)
The questions up for discussion is now:
* is this a valid use case at all? We can argue that of course the
grokkers for base classes should kick in. Normally when you subclass the
behavior of the base class is still intact, why do it differently with
* in what kind of concrete implementation scenarios is this necessary?
* are there alternative possible solutions to these problems?
I can imagine a rule for Martian like this:
If you have grokkers A and B, where B is a subclass of A, and we have
classes X and Y, where Y is a subclass of X, and A groks X and B groks
Y, we don't want grokker A to kick in as well, as it indirectly kicks in
being a superclass of B.
Rules like this might be complicated to follow though, so I'm not sure
about it. Opinions?
Alternatively we could introduce some directive to control this:
If this is defined on your grokker, it will be the only grokker for that
object. This may be a bit excessive though - you might block off too
many grokkers for your own good this way.
In order to figure out whether any of this is necessary we really need
to be specific and concrete about our use cases first. Fernando, could
you try to spell this one out again? Not just what you're trying to do
in code, but also why you're trying to do it, and what your final goal
is that you try to accomplish.
More information about the Grok-dev