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

[Gary Poster]

On Sep 9, 2009, at 10:02 AM, Martijn Faassen wrote:

> Hey,
>
> Gary Poster wrote:
> [snip]
>> 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  
> global
> utility registration right now. You'd also need a  
> grok.provides_utility
> 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.

OK, granted.

> 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.  
> One
> needs to trace base classes. But this is a fairly common thing an  
> object
> oriented developer needs to do anyway, and it won't be long before  
> they
> 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  
> adapter
> 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)
>     grok.creates(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.

Gary