Navigating traits in 3.9
adi at netstyle.ch
Mon Oct 23 07:38:19 UTC 2006
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
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
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!
More information about the Squeak-dev