[Grok-dev] Re: Grok naming issues.

[Lennart Regebro]

On Sun, Apr 27, 2008 at 7:20 PM, Martijn Faassen <faassen at startifact.com> wrote:
>  I don't see how it matters for grokkers under what namespace they are. It
> only matters for the components (base classes) that are being grokked.

You are right, I was being unclear.

>  I think the name "plone.grok" is probably not a good idea. The name "grok"
> implies that there are base classes you can import from it to inherit from,
> so that your classes will be grokked. It implies that there's some form of
> compatibility layer with grok. That's true for "five.grok", but not, as far
> as I understand, for "plone.grok". I think it shouldn't be called that way.

Well, there is one, for the GenericSetup import step.
(Actually there are three, but the two others just subclass existing
classes and are not needed).

>  If there are to be Plone base classes that are to be grokked that are not
> already defined somewhere else, place them in another namespace that isn't
> called "grok". It's not a compatibility layer. I think in many cases you'd
> write grokkers for existing Plone base classes instead, though?

Good point. plone.grok doesn't make as much sense as plone.grok. One
drawback with this is that you will have to, as a newbie, know from
where things come. What is a part of five.grok, what isn't? On the
other hand, for the cases where we do not have Plone baseclasses,
maybe we simply should make them? Maybe the plone.grok.ImportStep
baseclass in fact should be Products.GenericSetup.ImportStep?

>  I think we should absolutely should avoid special namespace manipulation.
> Namespace manipulation is a recipe for confusion for everybody. I've had my
> fill of namespace confusion when I ran into "PyXML replaces the 'xml'
> namespace in the standard library" issues. It's a form of monkey-patching
> and therefore should be avoided.

Sure. And I just on my way home from the sprint realized that if you
wanted to use a module written for grok in grok.five, you as the
"user" can do that manipulation yourself, quite easily.

>  People shouldn't add grok as a dependency if they're not using Grok. :)

That's my point. If we make namespace magic so five.grok is used by
"import grok", people will do this, though.

> Anyway, this kind of breakage is hardly a huge risk; it's something a
> developer might try and figure out very quickly it's not a good idea.

And then they'll go "Grok sucks" to all their friends, because it didn't work.

>  Maybe one day "grok" as a package will run under Zope 2, unchanged. Until
> that day, supporting "import grok" in Zope 2 is a lie we don't
>  want to tell.

Good point.

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64