> super/subclass. A MessageSet does less things than a Browser.

Hmm, no it doesn't.  It sounds like you're thinking of a "Browser" as
a PackagePane browser.  In fact, a PackagePaneBrowser is-a Browser
just as a HierarchyBrowser is-a Browser just as a MessageSet is-a
Browser.  Hope that helps.

> Indeed, my basic strategy is to store the Symbol or String name of the
> viewed thing rather than the index. So
>
> | b |
> b := Browser new.
> b selectedSystemCategory: 'Tools-Browser'. "I want to change this to
> #selectSystemCategory: - better reading, and more uniform with the existing
> style, like #selectClass:"

I appreciate wanting to use verbs / terse-English, but I think for the
ToolBuilder API, it is better to stick to uniformity between the
getter and setter; #selectedSystemCategory and
#selectedSystemCategory:.

> I think it's wiser to use strings/symbols rather than actual entities
> because sometimes we don't have reified entities(system categories, message
> categories). Also, Browser works entirely on lists of names at the moment,
> rather than lists of objects (classes, methods) with names.

With the PackagePane browser our categories are just Strings anyway; I
wasn't referring to those lists.  I'm talking about the lists which
render Objects other than Strings, like the various message-lists.  OO
user-interfaces should present original MethodReference objects
directly, not Stringified copies.

Making Stringy copies is a "relational", not OO-paradigm, because then
you have to always "look up" the real object based on the selected
String, etc. which is more complex, more garbage, etc.

 - Chris