[Grok-dev] changing martian to support class decorators

[Martin Aspeli]

Hi,

On 21 March 2011 17:58, Martijn Faassen <faassen at startifact.com> wrote:
> Hi there,
>
> Prompted by discussions on zope-dev and a conversation with Souheil I
> looked a bit at Martian to see what would be required to support class
> decorators.
>
> There are two alternatives I can see concerning syntax. One is to turn
> the directives into decorators:
>
> @grok.context(Foo)
> @grok.name('bar')
> class MyClass(...):
>    ...

+1

> the other is to use a single decorator to kick things off:
>
> @grok.config(
>    grok.context(Foo),
>    grok.name('bar'),
>    )
> class MyClass(...):
>     ...

-1

It's not clear what benefit you get from the extra @grok.config as an
integrator/end user: it's just more typing for the same thing.

> We have another issue if we care about Python 3 support: module-level
> directives. These use the same frame hack, but I expect this will fail
> to work for the same reasons. Can we come up with a way to spell module
> level directives differently? Perhaps like this?
>
> module_config = grok.module_config(
>    grok.context(Foo),
>    )

+0 - what's the module_config variable for?

> or maybe this:
>
> @grok.context(Foo)
> class ModuleConfig(object):
>    pass

-1 -- I really don't like the idea of classes used just for
configuration with no body or Python implementation logic. It feels
like language abuse. For the same reason, I prefer ZCML for defining
permissions and resource directories instead of "faux" classes like
grok.Permission and grok.ResourceDirectory.

It may be worth looking at the pattern that Google Guice uses:
basically the template method pattern. It may look like:

class ModuleConfig(grok.Config):

    def configure(self):
        this.setDefaultContext(IFoo)
        ...

> Another approach, which I'd like to avoid if at all possible, would be a
> code conversion tool.

Yes, please - I don't think that's workable.

> Yet another approach would be to expose *two* sets of directives per
> grokcore package, one old-style, the other new-style. But
> 'grok.context()' reads so nicely I don't want to give it up...

I think people would get very confused by this and we'd end up with mismatches.

Martin