[Grok-dev] Re: Grok nomenclature
faassen at startifact.com
Wed Apr 30 03:09:02 EDT 2008
Martin Aspeli wrote:
> 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):
> 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):
> Again, better suggestions welcome.
I don't like either option very much.
On option 2): Martian is, I think, too low-level for what you'd
typically do. The 'martian' namespace already exists, and doesn't define
any policy. That's a good policy - Martian is about infrastructure to
construct directives and grokkers, but doesn't implement any concrete
directives and grokkers itself.
To go to an earlier point of yours:
> I believe that Grok patterns essentially invent "syntax" that implies
> a certain semantic behaviour.
I think this is a good point. The grok "syntax" can be seen as a kind of
domain specific language. Let's keep that perspective for a bit and
let's compare the rules of naming with that of a programming language,
* subsets of Python, such as 'rpython', 'tinypy' and 'pymite' typically
use the same ('if', 'else') for keywords. This would imply that if we
consider 'grok.*' as part of the Grok syntax (and I think it should, as
the 'grok' part is a clear part of what signals developers), we should
call it 'grok.*' even if we only have a subset (and thus my suggestions:
'import grokcore.component as grok')
* different implementations of Python have different names (CPython,
Jython, IronPython, etc). These names typically have 'Python' in it.
They are also all considered to be implementations of *Python* the
language. We don't really have a different implementation of Grok in
sight, so we don't need to worry about it.
* Martian is more like a language implementation tool than anything
else. Like a Python implementation may use a parser generator, someone
who wants to implement a grok-like language can use Martian.
* five.grok is not exactly a new implementation of the "Grok" language.
It's therefore not exactly like, say, IronPython or Jython. It's a
partial reimplementation (with much shared code) on a very much related
platform. There's some expectation that code written for Grok proper can
run on five.grok, though typically not without some modifications. I
think this compares, perhaps, with something like CPython on the Google
App Engine. We still consider it CPython, but it has different sets of
limitations and different behavior in some places.
* languages that are inspired by Python but aren't Python, such as Boo,
aren't called Python at all. Similarly extensions of Pythons (i.e.
libraries) aren't called "Python", though sometimes people call them
Looking at it from this perspective, I think something that is a variety
of Grok that implements the Grok language too (the specifics of the
language) can use the word "grok". It should also *distinguish* itself
from "Grok" proper, for instance by calling itself "five.grok".
When you actually *use* the language, the word 'grok' is part of the
"keywords", so I would suggest this would be the case of the use of the
language in all cases.
If you extend the language (by creating grokkers for new base classes,
or domain-specific directives), I don't think the word 'grok' should be
in play. I don't think much credit is needed either - mention Grok
technology but not much more. I think in fact it *shouldn't* reflect
that Grok is used in the APIs at all, I think it should use domain
specific APIs. So no 'martian' or 'grok' in the names at all, just
things like "Portlet".
I can see that, at least for a while, you want to distinguish the things
that are grokked automatically from the things
that you register from ZCML. You may have a "Portlet" base class that's
intended to be manually registered, and another one that registers
itself. I can see using something like the word 'Grokked' in front of it
to distinguish it ("GrokkedPortlet"), even though I think it isn't pretty.
Another alternative would be some investigations into signalling the
grokking in another way than using a base class. One thing we've
considered is looking for things to Grok by interface. That way you
could use the *same* classes as you already have, subclass from them and
add an interface and the right directives, and things are grokked. I
think this alternative sounds more attractive.
More information about the Grok-dev