[Grok-dev] Re: Grok nomenclature

[Martijn Faassen]

Hi there,

Martin Aspeli wrote:
[snip]
> 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.

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, 
Python:

* 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 
"py-something".

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.

Regards,

Martijn