[Grok-dev] concerns about grokcore.component.provides
gary.poster at gmail.com
Wed Sep 9 11:27:55 EDT 2009
On Sep 9, 2009, at 10:02 AM, Martijn Faassen wrote:
> Gary Poster wrote:
>> However, I'm also more convinced that the name of
>> "grokcore.component.provides" is a problem.
> I agree it's a problem, as this isn't the first time it came up.
>> My current preference is
>> for "provides_adapter". Reading this, I understand what the grok
>> directive is doing.
> One issue with this naming is that grok.provides is also used for
> utility registration right now. You'd also need a
> that does the same. The principle is to reuse directives if they do
> something similar enough, which one argue (also from the underlying
> code) is the case here.
> I also think there's a bit of a DRY violation in saying
> provides_adapter. The base class indicate it's an adapter. The
> directives specify how it's an adapter. In your example you have your
> own base class (CookbookTopLevelObject) that obscures this somewhat.
> needs to trace base classes. But this is a fairly common thing an
> oriented developer needs to do anyway, and it won't be long before
> realize it's an adapter.
Eh, I don't buy that as being an acceptable answer myself, but perhaps
we don't have to worry about it, since you give some alternatives
below that I like. :-)
> (this is an argument for a different-style martian that allows one to
> indicate what is being registered not by base-class but by directive:
> grok.adapter(), grok.view(), etc. That's another discussion and a much
> bigger topic, though)
A first-glance +1 to the idea, and +1 to not muddying the waters of
this discussion with it. :-)
> We still have the confusion of the word provides, which in ZCML
> means it
> provides an *interface*. I guess here it would mean "provides an
> of kind IFoo".
> Let's think about naming some more.
...(snip good replies to which I do not have a valuable rejoinder)...
> What do you think about:
> class FeaturedCookbookLink(CookbookTopLevelObject):
> grok.implements(ICookbookObject, ITopLevelEntryLink)
I like it a lot. This jibes with a lot of my thoughts lately--which
include the fact that, ideally, I'd like the terms "adapter" and
"utility" to be deprecated, and maybe even references to
zope.component to become unnecessary and rare. I won't muddy the
waters with that here though. So, +1 on "creates" from me.
That said, it works well for classes, but less so for functions, for
which the adaptation might be looking up an already-existing object
(this has existed, though I forget where). Leo's idea, from a
following email, is better suited to a theoretical use of adapters, as
they are used now. I prefer "creates" but then that's because I have
an agenda. :-)
Thanks! I'm really pleased by where this is going.
More information about the Grok-dev