[Grok-dev] Re: Grok nomenclature

[Martin Aspeli]

Hi Martijn,

Martijn Faassen wrote:
> 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.

You don't like my hastily put-together name suggestions, or you don't 
like the idea of this distinction?

I don't like the names, either. I *do* think we need to make a choice as 
to which of the two modes Grok wants to support.

> 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')

In this case, "Grok" has to relinquish some of its "brand name" as a web 
development framework so that other things can use the "grok.*" syntax. 
We'd need to be able to use "from plone.app.portlets import grok" as a 
convention.

I don't much like the "import foo as grok" convention, because it puts 
the onus on the user of the framework to use the convention, rather than 
on the framework authors to provide sensible (and findable) names.

> * 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.

Arguably, five.grok is kind of like a different implementation of Grok 
in the same way that Jython is of Python (since most of Jython's power 
comes from the same standard library that CPython uses, c.f. Grok vs. 
Zope 3).

> * 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.

Sure.

> * 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.

*shrug*

I guess it depends on the analogy you want to use, but like I said, this 
is the grey zone. I'm much more interested in what we want to do with 
things like Grokking of Plone portlet renderers, which have no Grok 
equivalent but wants to use Grok patterns and implementations.

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

Ok.

> 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".

I'm +0 on the five.grok issue, as mentioned, but let's not have this 
thread degenerate into a discussion on five.grok (we have the other 
thread for that).

> 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".

Here I disagree, actually. Right now, Plone people do:

from plone.app.portlets.portlets import base

class MyPortletAssignment(base.Assignment):
     pass

This is straigihtforward inheritance of a convenience base class.

What Lennart is doing is something like:

from plone.app.portlets import grok

class MyPortlet(grok.Portlet):
     pass

Here, grok.Portlet is adding a huge amount of semantic meaning to the 
MyPortlet class. It's going to register probably three different 
components, and make a lot of additional functionality available. 
However, if each and every framework or library that wants to use 
Grok-like conventions and patterns (surely a desirable thing, also in 
order to grow Grok-the-web-framework) were to invent its own name, then 
we'd have to go back to the documentation to work out whether 
'foo.Portlet' as a base class really means a base class or means 
something much more profound.

I think this boils down to an implicit-vs-explicit argument, but since 
we don't have enough syntactic power in Python we rely on explicitness 
of convention (grok.*) to signal behaviour.

> I can see that, at least for a while, you want to distinguish the things 
> that are grokked automatically from the things

I think forever. Not all base classes are going to be grokked.

> that you register from ZCML.

... or the things that are not components at all!

> 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.

Sure. Here we move the naming convention from before the dot to after 
the dot. Maybe plone.app.portlets.base.GPortlet?

The point is that we need a convention that's (a) visually appealing (b) 
clear and (c) consistent, so that we don't end up with 100 different 
ways of doing the same thing, making it hard to figure out what 
components actually get registered when you work with a complex package 
with potentially dozens of grokked things.

> 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.

Possibly, although it reduces some of the immediacy and familiarity of Grok.

Perhaps this debate is a bit like splitting hairs, but actually, when 
you go down the convention-over-configuration route, you're really 
talking about walking a tightrope of style and consistency. Get too 
"loose" and things will quickly become very hard to work with.

Martin

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