[Grok-dev] Re: final sprint report - please review my branch!

[Martijn Faassen]

Philipp von Weitershausen wrote:
[snip]
> I'm not really worried about that. I'm worried about making people 
> subclass something at all. It'll hinder the reusability of the 
> grokcore.component package.
> 
> For Grok-the-webframework, it's absolutely fine making people subclass a 
> specific class to gain functionality (grok.Model, grok.View, etc.), but 
> the supposedly-reusable packages shouldn't have to do that.

It's a mixin that doesn't actually do anything though, and it's dead 
simple. Since grokcore.component is about subclassing anyway (Adapter, 
GlobalUtility, MultiAdapter), I'd say this is perfectly acceptable.

If we take another approach, it'll have to compete in briefness with:

class MyObject(Context):
    pass

class MyAdapter(Adapter):
    pass

If we're concerned about subclassing, we can eventually expand Martian 
with the facility to recognize classes by interface as well:

class MyClass(object):
    grok.implements(IGrokContext)

I think this could then even be used to implement the base classes we 
have now (which I think are actually more readable):

class Context(object):
    grok.implements(IGrokContext)

I think such a thing is neat but of limited benefit, but it's something 
to thin about. Until we have such a thing, let's just stick with Context.

>> Are you thinking of, instead, introducing a directive with which
>> application stacks would mark up their classes as being eligible to be
>> automatically detected as adapter contexts?  Maybe grok.autodetect()
>> or something?
> 
> Yes, something like that. We won't be able to grok them because we can't 
> grok before we grok ;). Rather, I have some very simple registration in 
> mind that'll be part of the *meta* configuration (meta.zcml). I need to 
> write down a story for this first, though.

Please. I think you're going to have a hard time engineering something 
better than the elegant solution we already have. Going for a 
registration approach sounds way more complicated and I don't see any 
benefits so far. It also presupposes ZCML being used, which 
grokcore.component shouldn't have to require from a programmer who wants 
to use it.

Regards,

Martijn