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 
>> #addSelector:withMethod:notifying:.
> 
> 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?

Cheers,
   - Andreas