[Grok-dev] concerns about grokcore.component.provides

[Martijn Faassen]

Hey,

Leonardo Rochael Almeida wrote:
[snip]
> Thinking about this. IMHO, one syntax that would be clean enough for
> my tastes would be:
> 
> class MyFunkyAdaptor(NotNecessarilyGrokAdapterOrSubclass):
>     implements(IDestinationInterface, IAnotherInterface)
>     grok.adapts(from_=ISourceInterface, to=IDestinationInterface)
> 
> Notice this same syntax could be used with functions that act as adapters.
> 
> @grok.adapts(from_=ISourceInterface, to=IDestinationInterface)
> def MyFunctionAdapter(source_obj):
>     ....

Thanks for the feedback. At first glance your spelling looks attractive, 
but there are some problems (and some other comments and questions):

* NotNecessarilyGrokAdapterOrSubclass

   Let's defer that entire discussion. Right now it'll need to be a
   grok.Adapter or a subclass (or have its own grokker, but let's
   discuss grok.Adapter).

* how would you spell this for grok.GlobalUtility?

* we now use grok.context with both views and adapters. Your from_
   spelling breaks this.

* we now allow someone to not provide 'grok.context' or do a
   module-level grok.context. This isn't so easy to see with grok.adapts.
   The idea of sensible defaults relies on directives with few
   parameters. (the other pole of attraction is one directive
   which takes all parameters, some of which are optional)

* note that we already have a grokcore.component.adapter decorator for
   functions, which is like zope.component.adapter. It takes the
   thing that is being adapted, so is like grok.context in a way.
   The role of provides is taken by grok.implementer... (again
   following zope.component). I can never remember this, which is
   an argument for changing it. :)

I like the grok.context pattern we have.

So a possible spelling:

class Foo(grok.Adapter):
     grok.context(IWhatever)
     grok.implements(IFoo, IBar)
     grok.adapts_to(IFoo)

# assuming we can give directives such a double role as decorator.
@grok.adapts_to(IFoo)
@grok.context(IWhatever)
@grok.implements(IFoo)
def something(foo):
    ...

We need to decide whether we want grok.adapts_to to fulfill the role of 
grok.implements too in this context. This because it's clearer to see 
grok.adapts_to than it is to see grok.implements on an adapter - having 
adapts_to be required instead of grok.implements makes some sense. Even 
though it'd be overloading things.

For utilities:

class Foo(grok.GlobalUtility):
     grok.implements(IFoo)
     grok.utility_for(IFoo)

utility_for is not very symmetrical with adapts_to, however.

I'm not sure I like the idea of letting go of the identity between 
provides for utilities and adapters. If you consider function 
registration, you want a decorator that spells out that we're dealing 
with an adapter, but should we really let that affect the class?

We could also come up with a special decorator to mark what we're 
decorating for:

@grok.adapter
@grok.context(IBar)
@grok.creates(IFoo)
def something(bar):
    ...

Using such decorator anticipates us using class decorators in Martian in 
Python 2.6:

@grok.adapter
@grok.context(IFoo)
@grok.creates(IBar)
class MyClass(object):
    ...

(though the semantics of subclassing might change, so this should be 
carefully considered)

Regards,

Martijn