[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:
[snip]
> 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!
Regards,
Martijn
More information about the Grok-dev
mailing list