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

[Martijn Faassen]

Philipp von Weitershausen wrote:
[snip]
>> Do you really prefer people write this?
>>
>> class MyAdapter(plone.easyapi.Adapter):
>>     plone.easyapi.context(Adapted)
>>     plone.easyapi.provides(IFoo)
> 
> Sure. Or they can simply use it from grokcore.component. The point of 
> "plone.easyapi" surely isn't to provide solely adapters and utilities 
> but primarily other types of components.

Yes, the equivalents of the components in 'grok'.

>> This sounds terrible to me. Suddenly people have to mentally translate 
>> all the examples that already exist for Grok.
> 
> That's the last of my worries, really.

Well, it either needs a somewhat silly line on top examples ("in Zope 2, 
instead import 'import plone.easyapi' instead of 'import grok'), or a 
duplication of examples people can't see very quickly are related.

>> Do you really think people won't be writing: 'import plone.easyapi as 
>> grok' anyway? That's certainly what I'd be very much tempted to write 
>> if I wrote any examples for Zope 2!
> 
> Sure, but you're not writing a Grok application. You're writing some 
> extensions to Zope 2 (if you were using five.grok). If you were using 
> plone.grok, you'd actually be writing completely new components that 
> Grok didn't have, so here (and it seems we agree on this), using the 
> 'grok' name makes even less sense.

I don't think plone.grok is part of this debate; I see this as an 
entirely separate problem. I agree that plone.grok adds new components 
that Grok doesn't have, and that's why its name is out of the question. 
'five.grok' if it aims to replicate the Grok experience I think is named 
just fine.

>> Why can't Zope 2 have a package 'five.grok' that aims to provide the 
>> same API as Grok does?
> 
> Sure, Zope 2 could have it. Maybe we're not clear on what the goal of 
> five.grok is. I certainly don't see why it needs to replicate Grok all 
> over. If you start from scratch, you could just as well use Grok. If you 
> don't, then you're extending a legacy application. But then you don't 
> need (and possibly can't use) all of Grok.

I think a very significant chunk of what's in Grok is directly relevant 
to Zope 2. What in Grok *doesn't* below in a five.grok? Models, I can 
see - even though that might eventually change. I can also see that 
making 'grok.Indexes' work is a bit of work (though there is intid 
support for Zope 2 now, so it shouldn't be that crazy).

> I'd say in 99% of the cases 
> you just want views and perhaps viewlets.
> 
>> If we are careful to refer to this as 'five.grok' or 'Grok on Zope 2' 
>> I think we can tolerate the minimum confusion this should cause. 
>> Should we be that much afraid of Zope 2?
> 
> I'm not afraidof Zope 2, I'm afraid we have different understandings of 
> the word "Grok". 'Grok on Zope 2' is mostly about using a small subset 
> of Grok's technology. 

I don't see this as a small subset of the developer's experience.

> But Grok is so much more than just the technology. 
> It's also about the smooth ride (convention over configuration, KGS-like 
> version pinning, buildout scaffolding, etc.). Sure, we can replicate all 
> that for Zope 2, but what's the point? I think "Grok on Zope 2" has much 
> less ambition than our Grok (on Zope 3), and that's ok because like Five 
> itself, it's just meant to bring legacy apps up to speed.

Yes, it has less ambition, but I'd say it goes for the same APIs.

>> What if we ever get so far that "import grok" works on Zope 2 without 
>> modifications? Do we tell people that 'plone.easyapi' is now Grok 
>> after all?
> 
> If making "import grok" work on Zope 2 is your goal, then I think we 
> have very different goals.

It's not my goal, as I'm not a five.grok developer. But if I were a 
five.grok developer, that'd be the ultimate goal I'd be aiming for. I 
wouldn't expect to reach it for a long while, but I'd want everything 
else to work as easily as 'grokcore.component'. Probably requires 
changes in Zope 2.

>> I think you make a good point in that we should be clear that "Grok" 
>> is what we have created and develop here. If you are going to make a 
>> Grok for Zope 2, that shouldn't be referred to as "Grok" unless the 
>> context is unambiguous, but as "Five Grok" or something like that.
> 
> Or, as Brandon suggested, using the *verb* rather than the noun, e.g. 
> "Grokked Five" or "Grokking Zope 2" or whatever.

Well, I don't think we're really talking about the verb here. We're 
talking about the API and developer's experience, base classes and 
grokkers that have the equivalent effect in the Zope 2 context.

What's called "plone.grok" is about grokking Plone components, and I 
think the word 'grok' (or variations such as the verb) should simply not 
be used in the package name there, though "grokking" is of course a nice 
descriptive word of the process. I hope that can be folded into a bunch 
of base classes that are as much a part of their modules as the base 
classes are now. (neither do I think 'martian' should appear there, by 
the way).

Regards,

Martijn