[Grok-dev] Re: Grok nomenclature

[Leonardo Rochael Almeida]

On Fri, May 2, 2008 at 1:03 PM, Martijn Faassen <faassen at startifact.com> wrote:
> Hey,
>
> Brandon Craig Rhodes wrote:
>>
>> Anyway, the main thing I wanted to bring into this discussion is a
>> reminder of Philipp's idea a few weeks ago that we signal grokability
>> with an interface.
>
> Was it Philipp's idea? :) (Leonardo and myself brought it up I think)
>
> I think I earlier discussed implementing this directive as actually doing
> the adding of the interface. Just having the interface would indeed be
> enough. The base classes, in the hybrid/evolution scenario *wouldn't*
> implement that interface; you'll have to supply it itself for subclasses.
>
> [snip]

And speaking of me, I suggest this interface be 'provided' directly by
the class instead of implemented by it, EXACTLY so it doesn't get
inherited by subclasses.

This has two benefits:
 * The assignment of the interface can happen outside of the class,
which is good for highly-hybrid/third-party code, you'd rather not
change.
 * It is consistent with the use of interfaces and allows a future
path where the grokking itself is done by adaptation.

And speaking of this, we could have a Context metaclass instead of
base class, which on instantiation marked its classes as providing
this IGrokkable interface. This way we could handle "grokkability"
uniformily:

 * just providing the interface would be everything you needed to
check on a class (or on anything, for that matter)

* subclasses from classes of this metaclass WOULD get the interface
automatically as subclasses of grok classes do today.

* alien classes (or any kind of object) could still be marked with
this interface for grokking.

* we could eventually do grokking through adaptation[1]

Cheers, Leo

[1] thereby creating a very nice chicken-and-egg puzzle where we'd
like to write grokcore.component with itself :-)