[Grok-dev] Re: on the name "Grok"
Philipp von Weitershausen
philipp at weitershausen.de
Mon Apr 28 11:51:12 EDT 2008
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
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*.
> 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
> 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
> * 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.
More information about the Grok-dev