2006/7/11, Andreas Raab <andreas.raab at gmx.de>:
> 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 <andreas.raab at gmx.de>:
> >> 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
> >>
> >>
> >
> >
>
>
>