[Grok-dev] Re: grok.ILayer versus grok.Layer

[Philipp von Weitershausen]

Martijn Faassen wrote:
> Excuse me if I get stuff wrong; I haven't studied the layer branch very 
> much yet, this is just a response to something I heard from Philipp.
> 
> Philipp mentioned that the layer branch introduces grok.Layer, which is 
> really an interface. I'm a bit worried we're giving the wrong signals by 
> introducing an interface and then hiding away that is one by not 
> prefixing it with "I".
> 
> First the argument for not putting in the "I", as I see it:
> 
> Adding the "I" prefix leads to questions by the developer who may not 
> have a lot of experience with interfaces yet. They might get confused, 
> and wonder why they're defining an interface that they never implement. 
> In fact the request ends up providing those interfaces, and we don't 
> want to explain that to everyone right away.

Also, to me, grok.ILayer sends the signal that it's an interface *for* a 
layer. As a novice user i have no idea what a layer is but all of a 
sudden I'm supposed to define an interface for it. Of course, that's all 
bollocks, the interface itself is the layer, but that's not obvious.

Also, what kind of naming scheme are we trying to suggest? Grok is 
opinionated and definitely suggests patterns (which is good). Are trying 
to suggest that people should prefix their layers and skins with "I" 
too? Then we'll loose that nice spelling that we've come up with now:

   class Dresden(grok.Layer):
       pass

   grok.register_skin(Dresden)

   ++skin++Dresden

Having to call the layer IDresden would suck, I would have to spell the 
register_skin directive with an explicit name.

> The argument for including the I:
> 
> grok.Layer makes people think that Layer is a class. There are various 
> expectations you have when you see a class like grok.Foo:
> 
> * you might expect it to get grokked. This doesn't happen.

What's that supposed to mean? "Grokking" can mean many different things, 
so it's perfectly acceptable that grokking sometimes can mean that the 
respective object gets registered somehow, but sometimes it can also 
mean that nothing happerns.

> * you might expect you can use grok directives on it. That's not allowed 
> on an interface.

Ok, good point.

> * you might expect you can implement methods on it. You might try it, 
> and it seems to work, though you have no clue how to call them.

Ok, good point, though no example will show that this is possible. Also, 
we can make it pretty clear in the docs that it's not possible.

> * then you examine grok.Layer using, say, type(), it's actually *not* a 
> class but an instance.

Big deal :). Seriously, is that so much of an issue? How relevant will 
this actually be?

> In my mind, this makes the "I"s have it: I prefer the I prefix for 
> interfaces. Leaving it off sets up the wrong expectations. I realize 
> that this means we may have to explain the concept of marker interfaces 
> to users. This concept will come up one way or another anyway, and to me 
> having a marker saying clearly "wait a second, these things are special" 
> outweighs the value of "let's not bother people with things that they 
> don't need to know".
> 
> What do people think?

To sum up, I'm against the "I".


-- 
http://worldcookery.com -- Professional Zope documentation and training