[Grok-dev] Re: on the name "Grok"
faassen at startifact.com
Mon Apr 28 12:26:13 EDT 2008
Philipp von Weitershausen wrote:
>> * 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.
Why? It aims to provide the same API as Grok, after all.
>> 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.
five.grok is a web development framework. It doesn't work by itself, but
needs Zope 2 libraries (and Zope 3 libraries). Grok doesn't work by
itself too, it needs Zope 3 libraries. Anything else is a detail of how
things are installed. :)
Grok and five.grok allow the developer to do the same thing and aim for
API compatibility: write the same code and have the same thing appear on
their web page. The only difference is the underlying framework they are
integrated with (which is still largely the same, actually).
>> 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?
If the same code runs on Pylons, sure, that's a port of Grok to Pylons.
We're talking about grok.View and friends here too, naturally. Sounds
like quite a bit of work - this sounds like more work than the port of
TurboGears 2 to Pylons. :)
I don't think we're talking about the equivalent of a port to Pylons
here at all, though. We're talking about something quite different: a
port to the Zope 2 platform, which has the explicit aim of growing
towards Zope 3 and provides the Zope 3 libraries as well. The ultimate
aim would be the ability to run Grok on Zope 2, unchanged. We won't get
there any time soon, but we can make steps forward.
>> 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
We're not just talking about reusing the technology. We're talking about
aiming for broad (though likely not complete) API compatibility.
Anyway, I'd say something like: "five.grok" uses Grok technology to
allow you to use the Grok APIs in a Zope 2 context.
> 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.
I don't think this dilutes the brand of Grok. I think our brand is clear
enough to use it in a Zope 2 context. If we came out and said they
needed to use some other name on Zope 2, I think *that* would cause some
confusion, as many Zope 2 developers are well aware of Grok already and
are looking to use this technology.
I also think if we provide a library five.grok that works like Grok on
Zope 2, I think it'll be clear enough to people that this is not the
original Grok but a compatibility layer. This isn't that hard to explain
to people; this concept has been established quite thoroughly by Five,
Anyway, we need concrete risks, either developer confusion or to the
brand, of calling the import 'grok' in the Zope 2 context.
Calling it anything instead of 'grok' introduces a risk in my view.
Let's say they call it 'flurb' instead. Then suddenly people reading
Grok examples saying:
will have to know that they need to put in 'flurb.View' instead. I think
that's creating unnecessary mental work for people. To what purpose?
>> * 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.
I don't want to argue against people using a full import, but I also
don't see it as a problem if they used an 'import as grok', as we're
dealing with a strict subset. Either things work as expected with Grok,
or they don't work at all.
I don't think this discussion is very important compared to the others.
We can't really control what people 'import as' anyway in their own
code, and I think we can agree that the risk of this really confusing
the people who use these libraries is pretty limited. I can see benefits
to both approaches: grokcore.component is more explicit in the face of
possible future other libraries, while code using 'as grok' is easier to
read if you're already familiar with existing Grok code.
The important discussion is on 'five.grok' (and against the bad idea of
'plone.grok', but I think that's not particularly controversial).
More information about the Grok-dev