[Grok-dev] Re: final sprint report - please review my branch!

Philipp von Weitershausen philipp at weitershausen.de
Wed Apr 9 09:56:22 EDT 2008


Leonardo Rochael Almeida wrote:
> On Tue, Apr 8, 2008 at 5:51 PM, Philipp von Weitershausen
> <philipp at weitershausen.de> wrote:
>> Martijn Faassen wrote:
>>
>> [...]
>>> If we're concerned about subclassing, we can eventually expand Martian
>> with the facility to recognize classes by interface as well:
>>> class MyClass(object):
>>>   grok.implements(IGrokContext)
>>>
>>> I think this could then even be used to implement the base classes we have
>> now (which I think are actually more readable):
>>> class Context(object):
>>>   grok.implements(IGrokContext)
>>>
>>> I think such a thing is neat but of limited benefit, but it's something to
>> thin about. Until we have such a thing, let's just stick with Context.
>>  I like the IGrokContext idea. It's just as simple as subclassing 'Context'
>> (which we can still leave around). Sounds like a win-win solution.
> 
> Hey Martijn, this is the idea I was talking to you about on gtalk.
> 
> +1 from me as well.
> 
> Would it make any difference one way or the other if we used
> "classProvides()" instead of "implements()" for this?

Yes. In fact, a big one, because directly provided interfaces on classes 
aren't inherited. E.g. if you have

   class A(object):
       classProvides(IFoo)

   class B(A):
       pass

then B won't provide IFoo. And yes, it does make sense because A and B 
are not the same *object*. They are, in fact, instances of the same 
class (type) and A directlyProvides(IFoo) (classProvides is just 
syntactic sugar for that).

> Conceptually, I
> think it makes more sense to declare that a class provides a certain
> interface if we want to grok it. "implements()" declares things about
> what the future instance provides instead of declaring things about
> the class.

True, but I think the inheritance bit is important.

> In this case we could even use the the component architecture itself
> to look up the grokkers for a class (would that even make sense?).

That's a cunning idea. Perhaps we should explore this for the future. 
Like Martijn said, we're not a hurry for this.



More information about the Grok-dev mailing list