[Grok-dev] Grok nomenclature

[Martin Aspeli]

Hi all,

I just wanted to pull a proposal out of a longer thread on the name Grok:

I believe that Grok patterns essentially invent "syntax" that implies a 
certain semantic behaviour. For example, I may write:

   class Foo(grok.Utility):
       grok.name('foo')

In this case, the 'grok.' bits are signalling (to the Grok 
infrastructure, but also to me as a developer) that something profound 
is happening to the class "Foo" - it's being registered as a named 
component in this case.

I think we need a common naming convention or "pseudo-syntax" for these 
things, and I think that needs to transcend "Grok-the-framework". I very 
much support Philipp's view that this deserves to be protected like a 
brand name (let's not get into the five.grok grey area in this thread).

Perhaps Grok-the-framework should keep its pseudo-syntax prefix as 
'grok.', not at least because that's what's out there now and 
documented. However, if other packages are going to use Grok-like 
conventions and Grok infrastructure to achieve similar things, then we 
should at least standardise on conventions for how these should work. 
I'm coming at this from a Plone and Zope 2 perspective, but really it 
could apply to anything.

So - I think there are two options:

  1) Grok-the-framework wants to get credit for these ideas. In this 
case, we choose a name that's like Grok, but not quite Grok:

   class Foo(grokthis.Utility):
       grokthis.name('foo')

Better suggestions welcome!

  2) Grok-the-framework wants to protect its brand name and make the 
word "Grok" mean something very specific in terms of framework. In this 
case, we choose a name that's not like Grok at all. I think "martian" is 
an interesting one:

   class Foo(martian.Utility):
       martian.name('foo')

Again, better suggestions welcome.

The point here is to set a precedent for things like Plone that want to 
work with Grok-like conventions for specific things like portlets, but 
still let people familiar with Grok and other offshoots feel at home.

What do you think? Which approach does Grok want to take? What names are 
good?

Martin

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