[Grok-dev] concerns about grokcore.component.provides
faassen at startifact.com
Wed Sep 9 11:25:42 EDT 2009
Leonardo Rochael Almeida wrote:
> 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):
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
* 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:
# assuming we can give directives such a double role as decorator.
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.
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
Using such decorator anticipates us using class decorators in Martian in
(though the semantics of subclassing might change, so this should be
More information about the Grok-dev