[Grok-dev] Re: Grok nomenclature
Leonardo Rochael Almeida
leorochael at gmail.com
Fri May 2 12:52:41 EDT 2008
On Fri, May 2, 2008 at 1:03 PM, Martijn Faassen <faassen at startifact.com> wrote:
> 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.
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
* 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"
* 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
 thereby creating a very nice chicken-and-egg puzzle where we'd
like to write grokcore.component with itself :-)
More information about the Grok-dev