Hi Andreas,

On Oct 22, 2006, at 22:50 , Andreas Raab wrote:

> Hi Adrian -
>
>> Anyway, lets go through your problems step by step:
>
> Thanks, it is very much appreciated. BTW, I'm slowly getting a feel  
> for what exactly seems to be so hard about traits and their  
> relationships and I'll talk a little more about it below.
>
>>> Browsing the senders of the former netted me 9 places to look at  
>>> among which were four implementors of #addSelector:withMethod:.  
>>> And so began the tale of the traits...
>> If you had used the OmniBrowser tools as I suggested in the other  
>> mail you would see that among the 4 implementers of  
>> #addSelector:withMethod: there are 3 that do not implement the  
>> method locally but obtain it from a trait. This leaves us with  
>> exactly _one_ case to look at: TCompilingBehavior.
>
> That's strictly speaking correct, but lacks one critical bit of  
> information namely what the relationships between the other listed  
> entities are and whether they are relevant for the user. If this  
> were in a (single inheritance) class tree, I would want to look at  
> the hierarchy to figure out which of these places may turn out to  
> be relevant.

yes, this kind of information would be very helpful but is missing.

[...]

>>> Trying to find the users of TAccessingMethodDictDescription  
>>> leaves us fishing through menus with no success. "class refs"  
>>> does nothing, so does Cmd-Shift-N
>> Of course not. There aren't any references to traits in methods --  
>> just as there are usually no references to abstract classes.
>> Again, the problem is a missing UI. To get the users of a trait,  
>> do "TAccessingMethodDictDescription users"
>
> I think this needs fixing. Key relationships have always have menu  
> entries in the browsers - we don't ask people to print "FooClass  
> superclass" any more than we ask them to print "FooClass  
> subclasses" to figure out its dependencies. A simple fix could be  
> to change the wording from "class refs" to "users of ..." since  
> that works for both classes and traits and can do the right thing  
> dynamically based on the selection.

again, I agree.

> Same goes for "show hierarchy" where we really want to print a  
> combined tree for subclasses and traits to make clear what the  
> relationships are.

I attached a small screenshot of the TraitsOmniBrowser which for each  
class or trait shows a hierarchical view of how traits are composed.  
The browser probably needs some more work to make it reliable (just  
run into a problem) but then it would make a lot of sense to  
integrate it into OB which comes with the main distribution.

-------------- next part --------------
Skipped content of type multipart/appledouble-------------- next part --------------


[...]

> 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.

> Simply put my question is: How does TAccessingMethodDictDescription  
> come into play here? Why does it implement  
> #addSelector:withMethod:notifying: given that it is not a user of  
> TCompilingDescription and therefore not responsible for managing  
> adding/removing selectors (which is all handled in  
> TCompilingDescription)? If there is a relationship between the two  
> and that method, were is that relationship stated?
>
> 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?)

> Along the same lines, are you aware that TraitDescription uses  
> TTransformationCompatibility and ClassTrait (being a subclass of  
> TraitDescription) uses it, too? Is there a point which I'm missing  
> to that duplication? (I doubt it, in which case it's an interesting  
> data point about the complexities of understanding relationships  
> with traits and classes since I'd assume that at least a dozen  
> people have looked at it and missed that duplication)

Yep, you are right. Somebody added the trait a while back and I  
haven't noticed this problem!

[...]

Cheers,
Adrian