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

[Martijn Faassen]

Philipp von Weitershausen wrote:
[snip]
> 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.

Well, hiding it away won't make it stop being an interface.

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

That's a good argument against doing this that I hadn't considered. By 
the way, I would expect to lowercase the classname here, just like it 
does for views. Not doing it for layers feels inconsistent.

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

Well, you need to register it manually in order to make things happen. I 
wish we could somehow avoid this. It's another discussion, but what about:

class MySkin(grok.Skin):
    grok.implements(IDresden)
    grok.name('myskin') # this is actually the default

It's a misuse of implements(), of course. Perhaps we can find another 
directive instead. It also reuses grok.name. This also fits into our 
'postprocess' idea: people can implement that on their skin and expect 
their page templates be post-processed by it.

Was this considered before and rejected?

[snip]
>> * 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.

But it's actually possible. When people do it, nothing bad happens as 
the interface machinery interprets to be an IMethod. Relying on 
documentation saying "you can't do that" is not as good as the code 
itself saying "you can't do that". Though of course plenty of counter 
examples to this rule can be found. :)

Regards,

Martijn