[Grok-dev] Grok nomenclature
optilude at gmx.net
Tue Apr 29 16:26:59 EDT 2008
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:
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:
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:
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
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
More information about the Grok-dev