[Grok-dev] Re: on the name "Grok"

[Philipp von Weitershausen]

Martijn Faassen wrote:
> Hi there,
> 
> Since Lennart and Godefroid had such success with Grok in Zope 2, and 
> naming issues came up once again, I thought I'd sketch my idea on a 
> policy for the name 'Grok', and the package name 'grok'.
> 
> With just Grok, it's simple:
> 
> * you import from grok
> 
> * grokked components such as grok.View are in the grok namespace
> 
> * grok directives are in the grok namespace too
> 
> Then we had grokcore.component. This is a strict subset of Grok, that 
> Grok will be using itself, intended to be reusable outside of Grok:
> 
> * you do: import grokcore.component as grok

-1

You're right, grokcore.component is a subset, but it isn't Grok. Grok is 
the web framework. grokcore.component is something else much smaller. 
It's an implementation detail that's happened to be made reusable.

I strongly suggest using the name "Grok" for the web framework only and 
using other names for everything else. The same should apply to imports.

> * everything (both components and directives) works as a strict subset 
> of grok; you have adapters and such
> 
> * grok imports these things into its own namespace.
> 
> I think this usage is all right, as grokcore.component is considered to 
> be a strict subset of Grok. Using the name 'grok' here will lead to 
> relatively little confusion, and it *is* much prettier to use 
> 'grok.context()' instead of 'grokcore.component.context()'.
> 
> Now we have five.grok.

I'm against calling it five.grok, to be honest.

> This is a partial re-implementation of Grok.

No it isn't. five.grok is not a web framework. It's not integrated in 
any way. You may say I'm splitting hairs here (and you may be right), 
but conceptually I find grok and five.grok quite different. One is a 
framework, one is a library to extend another framework.

> It is a workalike to Grok in Zope 2:
> 
> * you do: from five import grok
> 
> * everything either works as Grok in a Zope 2 context, or not if 
> grok.five doesn't have that support yet.
> 
> * it reuses grokcore.component and imports this into its own namespace.
> 
> I also think this naming is all right, as five.grok tries to be an 
> implementation of the same module interface as Grok itself offers. It's 
> a port of Grok to Zope 2.

I disagree. If some package made Pylons controllers use martian and 
grokcore.component, would you say that'd be a port of Grok to Pylons?

> There is also 'plone.grok'. This provides plone-specific components and 
> grokkers, dealing with Plone specific concepts such as portlets. In 
> order to use it, you import from it. I think this name is very *wrong*.

Agreed.

> It leads people to believe that these base classes exist in Grok, which 
> they do not. It's not implementing standard Grok concepts at all, but 
> extends Grok. It therefore the namespace shouldn't have 'grok' in it. 
> Ideally it's just something that is folded into existing Plone packages.
> 
> I think using a new namespace looks fine for base classes. It may look a 
> bit ugly if you introduce new directives. Hopefully we can avoid these 
> most of the time, reusing standard grok directives. If a new directive 
> does need to be introduced, it *should* be in the same namespace as the 
> base class, unless we can somehow generalize it to Grok itself.
> 
> Absolutely out of the question is making the grok namespace 'magic', 
> where you can plug in your own things, just so things read smoothly. 
> Grok code is Python code. If see 'grok.foo', you should be able to go 
> look at Grok's __init__.py, follow the chain of imports, and find the 
> implementation. Importing it from other places is fine and standard 
> Python. But we don't want to use registries here, as this is a kind of 
> monkey-patching.
> 
> The general rules:
> 
> * ports to different platforms can be called 'grok'

I suppose this is were we disagree: For me, there's one "product" called 
Grok. It's a web framework with a friendly caveman called "Grok" for a 
mascot. It happens to be built using some technology. If that technology 
is reused somewhere else, it feels wrong to me to reuse the name Grok there.

I realize this is all about branding. But there must be a reason why 
Skodas aren't called Volkswagen, even though they reuse a lot of 
Volkswagen technology. It's so the Volskwagen brand isn't diluted.

> * strict subsets of Grok should be called 'grokcore.<name>'. When using 
> them, the user can use the word 'grok', in something like 'import 
> grokcore.component as grok'. That said, this only works if you use only 
> a single subset at the time.

And it makes everything very confusing. I'd say, if you're not using a 
combined package (e.g. 'grok', 'plone.awesomeconf', formerly known as 
'plone.grok', etc.) then just type out the imports. Explicit is better 
than implicit.

> * things that introduce new base classes or directives shouldn't be 
> called 'grok'
> 
> * imports should behave like normal python imports; no magic registry 
> behavior here.

Absolutely.