Navigating traits in 3.9
andreas.raab at gmx.de
Mon Oct 23 08:35:13 UTC 2006
Adrian Lienhard wrote:
> On Oct 22, 2006, at 22:50 , Andreas Raab wrote:
>> Well, as far as that goes, yes. But I'm still confused. Let's see:
>> After visualizing (e.g., writing down) who depends on what, what I
>> gathered so far is that TCompilingDescription is used by TPureBehavior
>> which is used by Behavior and TraitBehavior. And TCompilingDescription
>> itself implements both #addSelector:withMethod: as well as
> no, TCompilingDescription is not used by TPureBehavior. I guess, you are
> confusing TCompilingDescription with TCompilingBehavior.
You are right, it's TCompilingBehavior that I mean. But this just points
to the next issue: If I look at a browser I see both
TCompilingDescription and TCompilingBehavior next to each other. None of
the names make sense to me (what exactly is a "compiling behavior" and a
"compiling description"?) and there is no way for me to find out how
these entities are related other than by trying to find "matching
points" in the class hierarchy. Looking at TCompilingBehavior's users I
find TPureBehavior; looking at TCompilingDescription's users I find ...
"an IdentitySet(ClassDescription ClassDescription TraitDescription)".
Huh? Anyone else seeing this? An identity set with a duplicate entry?
In any case, unless I know already that TPureBehavior is used by
Behavior and TraitBehavior and that those are superclasses of the
classes listed here, there is basically no way to find out how these
entities relate. So basically, to find out how to traits are related,
I'm projecting them into the class hierarchy, look at the projected
inheritence tree and conclude from that projection how the traits are
related. I'm sorry, but this is ridiculous.
>> A "second order" question is: Why is it even possible to use traits in
>> such a conflicting way? Shouldn't there be some way of ensuring that a
>> protocol that is defined by a trait in a superclass doesn't get
>> redefined nilly-willy by a trait in a subclass?
> It does not look conflicting to me. At the level of Description the
> implementation of Behavior is extended (note also that
> TAccessingMethodDictDescription>>addSelectorSilently:withMethod: sends
> to super). In general, I think its a question of taste. (Do you want to
> be warned each time you override a method from the superclass?)
But they are _not_ superclasses. There is no (stated) relation between
those traits whatsoever. And that's exactly what I asked for: How do I
find out that these entities are indeed related and that the overlap in
the selector isn't just a random conflict?
More information about the Squeak-dev