> I'm not sure I buy this one. I like the convenience and
> simplicity that many of these provide. Writing
>
> 	'this is a text' encodeForHTTP
>
> seems a lot nicer than
>
> 	HTMLformatter encodeForHTTP: 'this is a text'

I think that this kind of thing stems from a deeper issue.  Although the
first form is much more convenient, it forces methods to be added to String
and therefore breaks the current System Category way of modularizing code.

I think we could have our cake and eat it too if we added an easy mechanism
to build modules.  This way, removing unwanted things would be easy by
simply having tools that could answer whether a module is used or not, and
having the developer decide what to do about each use in order to remove the
module.  So having useful methods like the above could still be provided for
without losing the ability to control whether we wanted the method or not.

A good friend of mine, Mark van Gulik, came up with a VERY simple technique
of doing modules which I REALLY liked.  It is very simple, easy to implement
and does not break anything that is in existense today.  Plus, the structure
of a module is encoded in the categories of the system in a very dynamic
fashion.  The scheme went something like this, and I do apologize if I miss
any details.  A module was defined as all System Cartegories and method
categories that included the same prefix in their names.  The module BASE
would contain all classes defined in System Categories named 'BASE-Classes',
'BASE-Views', and method categories like 'BASE-accessing', 'BASE-printing'.
The thing I find really cool about this mechanism is that NO new tools need
to be incorporated into the dev environment in order to provide support for
moving code around from one module to another.  All the structural
information is meta encoded in a way that all existing browsers can deal
with.  The only thing is, I don't remember how the pre-requisite information
was provided, I think it was just implicit in it's usage, but I'd have to
ask him.

Mark did end up building a module browser that used color in a very cunning
way.  I have the code and may port it someday, or if somebody else would
like to I can provide the code.  The colors were used to indicate what
System Categories contained classes and methods within it that belonged to
the currently selected module.  The only difference between the existing
browser and the current one was a drop down list above the System Category
list and usage of colors in the list panes.  One color was used to show that
the system category or method category contained methods in the selected
module, another color was used to show that the categories contained methods
in the current change set, another color to show that a category or class
was entirely made of of methods in one module, or a subset of its contents
was.  I am not being too clear, but I hope the basic idea is understood.

One of the cool things about this technique is that all tools built to work
with this dynamically computes the contents of a package based on what is in
the image at the time.  There were no funky tools to move things around and
find code, as the famous code suppository (oops, repository ;-) ENVY must
have.