[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):
>>> 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):
>>> 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
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