At 04:37 PM 12/18/2002 -0500, you wrote:
>	Method Categories and Class Categories are not part of the Smalltalk language!  They are user interface conveniences, and I generally just prefer to 'browse hierarchy' for classes and '--all--' for methods.  The categories create another completely unrelated organization of classes, which I find confusing because it has nothing to do with inheritance.  I may be the only one, but I just don't like the categories facility, and while I don't want others to be denied the choice, I want to be free to ignore categories and not use them if I choose.

Dean - Good point. Plus the categories lists take up UI space in the Browser that makes long class and method names hard to read. I, personally, happen to like having categories--I missed having method categories when I worked in VisualAge--but having all that UI space taken up by 4 seperate lists does bug me. But your message sparked an idea:

Why not collapse the category lists into the class and method lists--and then make the categories optional?

/Kernel-Objects/    | /accessing/
Boolean             | classPool
DepedentsArray      | name
EventMessageSet     | /accessing class heirarchy/
...                 | addSubclass:
/Kernel-Classes/    | removeSubclass:
Behavior            | subclasses
+CLASS++++++++++++++| subclassesDo:
Class Builder       | subclassesDoGently:
...                 | ...

Then you could add a menu item for each list that says "Show/Hide" categories.

(Hmmm...my proposal does seem like it would take a lot more effort to scroll through the now larger Class list to find the class you were looking for. But that just begs the question of how, in terms of the user interface, a programmer goes looking for a class in the first place. How often does a progammer know (from memory) which category a class is in so as to be able to use the category list in the first place?)

david

--
David Farber
dfarber at numenor.com