[Grok-dev] Naming of grok.provides

[Sebastian Ware]

23 okt 2008 kl. 10.30 skrev Sylvain Viollon:

>
>  Hello,
>
> On Thu, 23 Oct 2008 09:33:22 +0200
> Sebastian Ware <sebastian at urbantalk.se> wrote:
>
>> Who wants to bet that people will continuously misspell
>> registers_for as register_for... :) (or start misspelling
>> grok.require as grok.requires)
>>
>>
>
>  I don't want to troll, but I still prefer provides in fact. You can
> perfectly get the meaning with an explanation, same as register_for.
> People are not going to guess that directive, so you always need to
> say: to select which interface is _provided_ by your adapter, use ...
> And your going to say provided because you say that an object provides
> an interface.
>
>  I saw that it was complicated to get it because of
> providedBy/implementedBy:
>
>  Interface.implementedBy -> apply on class. Because a class implements
> an interface.
>
>
>  Interface.providedBy -> apply on an object. Because a object
> provides an interface. An adapter is used to build an object, to add  
> an
> interface to an existing object. So I think this makes more sense to
> use provides ... since you don't add functionality to a class, but  
> on a
> object.

Personally I think you have a point. It won't be intuitive whatever it  
is called. It just needs a very short explanation. I had to read the  
interface docs in schema.interface to find the explanation. I would  
like to see it in the developer notes (rather than the tutorial).

> Of course you can make adapter on classes, but that's not out of
> the box in ZCA.
>
>  I think maybe the problem is that people don't known what's a class
> and an object ... maybe they're not going to get what's an interface.

I believe most people will know the difference between a class and an  
object (well enough anyway), but understanding that you can actually  
manipulate the class (and objects) at runtime is obviously a feature  
developers from non-dynamic languages won't be comfortable with. So  
one might miss why one needs such a clear distinction between the two  
(at runtime) in the first place (i.e. why would I want to check if the  
class implents something? if an object of that class does so surely  
that means the class does and vice versa... but it doesn't...)

>  This should just be explained, if it's not already the case, in the
> grok tutorial. Such as: to do that blablabla. And in a note
> "terminology: you used an interface, what's an interface and so on".
>
>  If people don't known what they are doing, they will always complain
> that they don't get it, so that don't work, and since this don't work
> that's a bad framework. More or less.

How dare they... :p

mvh Sebastian