[Grok-dev] Naming of grok.provides
sebastian at urbantalk.se
Thu Oct 23 04:55:57 EDT 2008
23 okt 2008 kl. 10.30 skrev Sylvain Viollon:
> 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
> 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
> 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
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
More information about the Grok-dev