[Grok-dev] Re: Grok nomenclature

[Martin Aspeli]

Martijn Faassen wrote:

>> How about:
>>
>>  class MyPortletAssignment(base.Assignment):
>>      grok.as('plone.portlet')
>>
>> This would look up a named grokker called 'plone.portlet' that would be 
>> able to grok this type of class. 
> 
> This sounds like repeating yourself, if the class already can signal 
> what class could be used.

I suppose that's true.

>> I would also make it possible to 
>> parameterise this, so e.g.:
>>
>>  class MyPortletAssignment(base.Assignment):
>>      grok.as('plone.portlet', name='my_assignment', for_=IFoo)
>>
>> In pseudo-code, grok.as() would be:
>>
>>  def as(_grokker_name, **kwargs):
>>      grokker = getUtility(IGrokker, name=_grokker_name)
>>      context = sys._getframe(1)
>>      grokker.grok(context, **kwargs)
>>
>> This is a fairly fundamental shift, though. :)
> 
> Yeah, this sounds like reimplementing ZCML as grok directives.

*shrug* the point was more to making the "parameters" to the grokker be 
done as keywords rather than descriptors, so maybe:

   class Foo(Base):
       grok.grokked(name='foo', bar='baz')

instead of

   class Foo(Base):
       grok.grokked()
       grok.name('foo')
       grok.bar('baz')

The advantage being that in the first instance, there's only one 
"namespace" and things are being kept closer together. It may not be 
much of an advantage in real life, though.

> This is a huge shift, as you say before. I'm not much in favor of it. 

I'm not sure I am either, just playing with ideas.

> Grok directives have the benefit that they typically take one or a few 
> parameters, not a whole slew. This makes it possible to leave individual 
> ones out. You can do this with keyword parameters, but I think it makes 
> it much less readable. You'd also need a very different implementation 
> of directives to be able to do a declarative definition of the 
> defaulting rules (and we're moving towards such declarative 
> definitions). Note that Uwe Oestermeier has such a system - it's much 
> closer to ZCML than Grok is, but is inline in Python code.

Ok.

> Yes, perhaps. I'm wary of such conventions, as we don't need them in 
> Grok, and I prefer code without such conventions, trying to exploit 
> namespaces in Python instead to mark conventions. I don't think a 
> grokked class is as fundamentally different than an interface is from a 
> class (where we do have a consensus about the I* convention).

I guess that's what it comes down to - if it *is* as different, then 
some kind of convention is probably needed.

> I realize that using conventions is more attractive if you are evolving 
> code forward that doesn't use Grok yet. That said, I still hope for an 
> end result of the evolution where there is a package which just has 
> classes, and that knowledge of whether it needs to auto-register is 
> actually not very relevant to the programmer. It's an implementation 
> detail, just like whether a meta-class is in use should be an 
> implementation detail (where, as you'll note, no conventions are in use 
> to mark them out either).

Mmm... I'm not sure that's a desirable end goal if taken to extremes. 
Yes, it makes sense for some primitives (like views, say), but if I 
suddenly get a lot of new behaviour by subclassing something, and that 
fact is hidden away from me, it'd be hard to debug and understand.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book