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

[Philipp von Weitershausen]

Martijn Faassen wrote:
> 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.

It is as long as you're fine with actually creating new classes. If 
you'd want to make existing classes implicit contexts, you're out of luck.

> 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.

I like the IGrokContext idea. It's just as simple as subclassing 
'Context' (which we can still leave around). Sounds like a win-win solution.

>>> 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.

True