Hi Folks -
Just curious, but how do people navigate traits today? I'm completely overwhelmed by seeing twenty "implementors" of a message that originates from a single trait and is merely used in twenty places. The browsers, senders, implementors really do nothing to filter any such methods. It's *very* painful even trying to understand along which lines the metaclass kernel is now structured if you can't even tell what is an actual implementor and what is simply inherited ("used" for traits but it's effectively the same). How do other people deal with that? Do you really browse to a class and compare the traits listed in its definition with the ones you see in implementors, and then browse to that trait and do the same? That's what I've been doing today and ... shall we say ... it is not particularly effective ;-) Any advice on better practices would be hugely welcome. BTW, why are these messages displayed at all? We don't show other inherited methods either so what's so special about traits method that they need to be shown in multiple places by default? Cheers, - Andreas |
Use a trait aware browser. The OmniBrower in the image has very basic
trait support (ie. shows that a method is added via a trait). The TraitBroswer (see earlier thread) has better trait support but is still lacking in some places (ie it's not yet directly possible to browse all users of a trait). 2006/7/11, Andreas Raab <[hidden email]>: > Hi Folks - > > Just curious, but how do people navigate traits today? I'm completely > overwhelmed by seeing twenty "implementors" of a message that originates > from a single trait and is merely used in twenty places. The browsers, > senders, implementors really do nothing to filter any such methods. It's > *very* painful even trying to understand along which lines the metaclass > kernel is now structured if you can't even tell what is an actual > implementor and what is simply inherited ("used" for traits but it's > effectively the same). > > How do other people deal with that? Do you really browse to a class and > compare the traits listed in its definition with the ones you see in > implementors, and then browse to that trait and do the same? That's what > I've been doing today and ... shall we say ... it is not particularly > effective ;-) > > Any advice on better practices would be hugely welcome. BTW, why are > these messages displayed at all? We don't show other inherited methods > either so what's so special about traits method that they need to be > shown in multiple places by default? > > Cheers, > - Andreas > > |
I tried OB for some fifteen minutes but it seems to be quite a bit away
from production quality. To name a few of the issues I ran into: - errors when looking at class comment or hierarchy in the browser - lockups when trying to "browse hierarchy" on Behavior and friends - errors when trying "browse hierarchy" on traits - "browse" in a message list navigates to the class instead of the trait where the method is implemented And so on. There were also a few weird places where methods showed up as being implemented nowhere (e.g., all items in the list where italics which I presume means it's not implemented in this place) even though their users showed. Don't remember where it was just the final nail in the OB coffin for the time being ;-) As for TraitBrowser, where can I get it? Cheers, - Andreas Philippe Marschall wrote: > Use a trait aware browser. The OmniBrower in the image has very basic > trait support (ie. shows that a method is added via a trait). The > TraitBroswer (see earlier thread) has better trait support but is > still lacking in some places (ie it's not yet directly possible to > browse all users of a trait). > > > 2006/7/11, Andreas Raab <[hidden email]>: >> Hi Folks - >> >> Just curious, but how do people navigate traits today? I'm completely >> overwhelmed by seeing twenty "implementors" of a message that originates >> from a single trait and is merely used in twenty places. The browsers, >> senders, implementors really do nothing to filter any such methods. It's >> *very* painful even trying to understand along which lines the metaclass >> kernel is now structured if you can't even tell what is an actual >> implementor and what is simply inherited ("used" for traits but it's >> effectively the same). >> >> How do other people deal with that? Do you really browse to a class and >> compare the traits listed in its definition with the ones you see in >> implementors, and then browse to that trait and do the same? That's what >> I've been doing today and ... shall we say ... it is not particularly >> effective ;-) >> >> Any advice on better practices would be hugely welcome. BTW, why are >> these messages displayed at all? We don't show other inherited methods >> either so what's so special about traits method that they need to be >> shown in multiple places by default? >> >> Cheers, >> - Andreas >> >> > > |
2006/7/11, Andreas Raab <[hidden email]>:
> I tried OB for some fifteen minutes but it seems to be quite a bit away > from production quality. To name a few of the issues I ran into: > - errors when looking at class comment or hierarchy in the browser > - lockups when trying to "browse hierarchy" on Behavior and friends > - errors when trying "browse hierarchy" on traits > - "browse" in a message list navigates to the class instead of the trait > where the method is implemented Thanks for reporting these issues. > And so on. There were also a few weird places where methods showed up as > being implemented nowhere (e.g., all items in the list where italics > which I presume means it's not implemented in this place) even though > their users showed. Don't remember where it was just the final nail in > the OB coffin for the time being ;-) > > As for TraitBrowser, where can I get it? >From the "Traits Browser Availability" Thread: In 3.9b 7033, using Monticello browser, from the http://monticello.wiresong.ca/ob/ repository, load OB-Tests-Core-cwp.1.mcz (This will allow you to run the associated s-unit tests for OmniBrowser and is a prereq to run the tests for Trait Structure Browser) And from the http://kilana.unibe.ch:8888/TraitsOmniBrowser repository, load TraitsOmniBrowser-tlk.38.mcz If you select and run OB-Tests-Core and TraitsOmniBrowser-Test test in TestRunner, it should run 173 tests with 165 passing. The 3 failures and 5 errors appear in OB-Tests-Core w/o the Trait Structure Browser changes. If you get different results then I've probably failed to classify some overridden method a *TraitsOmniBrowser. In a work space, do OBTraitStructureBrowser open To see the difference between this browser and the default SystemBrowser, do a find on Behavior, and explore the treatment of trait compositions and the virtual method categories. OBTraitStructureBrowser seems to be working as far as it goes. We still need to add a fair bit of functionality from Browser (e.g. you can't do a find on a Trait) and the Traits Browser as described in the papers (e.g, no easy way to change a method in the trait versus in the using class). This version is probably worth others trying. The latest version is mine, but of course Adrian and Daniel have done all the heavy lifting. > Cheers, > - Andreas > > Philippe Marschall wrote: > > Use a trait aware browser. The OmniBrower in the image has very basic > > trait support (ie. shows that a method is added via a trait). The > > TraitBroswer (see earlier thread) has better trait support but is > > still lacking in some places (ie it's not yet directly possible to > > browse all users of a trait). > > > > > > 2006/7/11, Andreas Raab <[hidden email]>: > >> Hi Folks - > >> > >> Just curious, but how do people navigate traits today? I'm completely > >> overwhelmed by seeing twenty "implementors" of a message that originates > >> from a single trait and is merely used in twenty places. The browsers, > >> senders, implementors really do nothing to filter any such methods. It's > >> *very* painful even trying to understand along which lines the metaclass > >> kernel is now structured if you can't even tell what is an actual > >> implementor and what is simply inherited ("used" for traits but it's > >> effectively the same). > >> > >> How do other people deal with that? Do you really browse to a class and > >> compare the traits listed in its definition with the ones you see in > >> implementors, and then browse to that trait and do the same? That's what > >> I've been doing today and ... shall we say ... it is not particularly > >> effective ;-) > >> > >> Any advice on better practices would be hugely welcome. BTW, why are > >> these messages displayed at all? We don't show other inherited methods > >> either so what's so special about traits method that they need to be > >> shown in multiple places by default? > >> > >> Cheers, > >> - Andreas > >> > >> > > > > > > > |
Free forum by Nabble | Edit this page |