[Grok-dev] grok.ILayer versus grok.Layer
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