Dean Swan <Dean_Swan at Mitel.COM> wrote:
    Method Categories and Class Categories are not part of the Smalltalk
    language!

True.  There is nothing about them in the ANSI Smalltalk specification,
and the ANSI Smalltalk interfchange format has no provision for such
information.

    They are user interface conveniences,

But they are so AMAZINGLY convenient.

Let me put it this way:  if you are writing new code, you don't need
this stuff, but if you are trying to find your way through someone
else's existing code, they are life-savers.

Method categories in particular provide important 'meta-information'
about what a method is _for_, and provide a way to locate methods
when you have not the slightest idea of what their name might be,
but do know what they're for.

I'm in the process of writing some Smalltalk code (4700 SLOC so far and
rising steadily) that has nothing to do with Squeak, and even though I
know what every line is, and there are only about 70+ classes so far,
I find myself wishing for class categories and message categories.

    One could also argue that if your class has so many
    methods that you need method categories, that you should think about
    refactoring it into more than one class anyway.

To my way of thinking, this completely misses the point of method
categories.  They are NOT a way of chopping up a huge lot of methods
into managable groups, they are a way of providing important information
to other people so that when they are interested in what conversions to
other types are on offer, they go go straight there without having to
look at anything else.  Even if there is only one other method, NOT having
to read it to figure out that it isn't relevant is a win.

What I often find myself wanting is a 'flattened' view showing all the
inherited-and-not-overridden methods as well, NOT as a great long list
such as 'protocol' gives me, but as a two-pane browser with method
categories.  If I want to know what enumeration methods are available
for some class, I *don't* want to have to wade through everything
inherited from Object to get there, I just want to look at the enumeration
methods.

Eiffel has something similar to the class categories idea, in that
Eiffel methods can have a lot of semi-structured "indexing" information
added at the top.  There's a defined syntax for placing that information
and Eiffel tools know about it, so you can find classes related to a
particular topic.  What Eiffel _doesn't_ have is method indexing.
Class/method categories are perhaps a simplistic kind of indexing,
but they are better than *NO* indexing.