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

Martijn Faassen faassen at startifact.com
Thu Apr 19 12:34:01 EDT 2007


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.

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.

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

* 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.

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

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?



More information about the Grok-dev mailing list