[Grok-dev] Re: let's rename grok.baseclass() to grok.ignore()

Martijn Faassen faassen at startifact.com
Tue Mar 18 17:39:52 EDT 2008

Brandon Craig Rhodes wrote:
> I have a nagging feeling this argument will be easy to knock down, but
> I'm a bit tired and will let you guys do it instead. :-)

I'll try to knock it down.

I'm -1 on this change. I don't think grok.baseclass() is bad, and even 
if it were, I don't think it makes sense to go changing it now.

The best reason to call it 'baseclass' is that the behavior isn't 
inherited. If you use 'grok.ignore()' you might expect all subclasses 
would also be ignored. I think grok.baseclass reflects the purpose better.

The case where you want to use it for another purposes than being a base 
class is interesting, but I'm not sure you got a decent use case just 
yet. If you want to configure an object yourself the Zope 3 way, I'd 
suggest not subclassing from any Grok baseclass altogether. Mixing the 
two configuration strategies for the same object is asking for confusion 
(in both the writer and the reader). There might be things that ZCML 
directives can do that the Grok equivalent can't do yet, but I can't 
think of any cases. Those cases would actually be very interesting to 
hear about!



More information about the Grok-dev mailing list