Daniel,
I'm sorry to start a new thread on traits but I can't keep up with the volume of discussion in the other threads. At this point I'm excited (with some small reservations) about traits. I played with the demo image a bit and simply want to make some comments regarding the UI tools. In order to avoid significant flaming let me first say that these comments are offered with only constructive intensions...I think traits will prove to be very useful...and I am also aware that much work is still in progress on the tools. Finally I appologize if you've heard these already...
1) I cannot, at a glance tell, where a given class is getting its implementation of a method. This makes it a lot more cognatively difficult to decide _where_ to edit source. Some visual indicators are desparately needed here. For example, in OBTraitTransformationNode if I look at the #name method I get no indication that it is coming from the Trait. If I edit #name I have now overriden the version in TTraitNodeDisplay but can't tell that without a lot of pointing and clicking. The current display method is contrary to what is done in class hierarchies (a method is not displayed unless it is present in the class being viewed...superclass methods are not shown). I think having the trait methods visible in the class itself are OK but require a) text or icon annotations, b) a preference to turn them off. VW, for example, allows you to view superclass methods but it displays the class of origin next to the method name.
2) If I browse implementors of the method #name, I get a hierarchy showing me that Object implements name and below it (and properly indented) I can see who overrode that version. This paradigm is not followed with Traits, however. In the example from part 1 if I override #name in OBTraitTransformationNode I get no visual indication in the implementors browser that said "user" of the trait TTraitNodeDisplay overrides its method. In my opinion OBTraitTransformationNode should be listed twice (once in the Object hierarch and once in the TTraitNodeDisplay hierarchy).
3) If I browse references to a trait I get an empty list (I think it should show all class defs which "use" the trait)
4) There are bugs. Just doing a find (alt-f in the class category panel) and entering a trait name raises a debugger for me.
Thanks for this exciting work!
David
Since some people have been giving actual feedback, and managing feedback by email is really not that effective, we've opened a new Traits category for bugs under Mantis, under the Squeak category.
Please feel free to stuff it full of high quality bug reports, if they're in Mantis we won't lose them.
David Shaffer wrote:
1) I cannot, at a glance tell, where a given class is getting its
implementation of a method. This makes it a lot more cognatively difficult to decide _where_ to edit source. Some visual indicators are desparately needed here.
Sure. These correspond to the -own- virtual method category, and "provided selectors appear in green" features of the Prototype image. These are not hard to do in the OB, and were pretty much planned, and are clearly really needed. They are mentioned in the first bug report in the Traits category, which I've entered myself at: http://bugs.impara.de/view.php?id=1762
You're welcome to add details there if you feel the need.
Note that at least some of this functionality needs to be in the Debugger, so people don't override methods when they think they are fixing them, but this is not on my agenda. Help will be welcome on this front after the merge.
- If I browse implementors of the method #name, I get a hierarchy
showing me that Object implements name and below it (and properly indented) I can see who overrode that version. This paradigm is not followed with Traits, however. In the example from part 1 if I override #name in OBTraitTransformationNode I get no visual indication in the implementors browser that said "user" of the trait TTraitNodeDisplay overrides its method. In my opinion OBTraitTransformationNode should be listed twice (once in the Object hierarch and once in the TTraitNodeDisplay hierarchy).
Well, like it or not, Traits do change the situation we used to have where overrides lived in hierarchy. So while what you propose is certainly one way to deal with things, I'm not sure its the best, and at the moment I feel like more experience is needed to decide which is. You can still report it on mantis, of course.
3) If I browse references to a trait I get an empty list (I think it
should show all class defs which "use" the trait)
Ah. That makes sense. Please report this one on Mantis
4) There are bugs. Just doing a find (alt-f in the class category
panel) and entering a trait name raises a debugger for me.
Yes, this one is already fixed in my image, will get pushed out next time.
Thanks for this exciting work!
Thank you for straight-to-the-point feedback!
Daniel
squeak-dev@lists.squeakfoundation.org