[Grok-dev] overriding Grokkers

[Martijn Faassen]

Hi there,

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 
grokkers?

* 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:

grok.onlygrokker()

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.

Regards,

Martijn