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

[Martijn Faassen]

Hi there,

Philipp von Weitershausen wrote:
[snip]
>> * 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.

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

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, 
after all.

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:

class MyView(grok.View):
    pass

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

Regards,

Martijn