Stef,

> >  Look for instance at Utilities class comment. It
> > says: 'methods that don't naturally attach to anything else'. These
> > methods are functions and you won't create instances of the new
> > classes, they are just more or less function-holders. There is no
> > complicated interdependency of classes and methods to understand. It
> > is only a question of 'listing' these functions.
> 
> If this is what **you** believe...

And me too. If there is a recognizable concept for a number of methods which
make sense to think about them as "attached to" a common class (system
navigation for example) then I'm all for it. But in many other cases we
merely have utility functions and forcing "arbitrary concepts" will only
make things more complex - mostly you will start moving around the methods
for the mere purpose of putting them NOT into a specific place which means
you'll have much more confusion in the long term.

For example, consider a method like #abandonSources. I don't see any easy
place where this method should live and if you would forcefully "clean up"
SystemDictionary then all you know is that you do NOT want it there - but
you've got no good concept yet where to stick it otherwise. Let's consider
someone says "let's put this into FileDirectory" because it does something
with files. Now, any code has to be rewritten against file directory. Except
that at some later point someone might say "oh, it really belongs into
FileStream" and then any code has to be rewritten against that place. And so
on. In the long-term, there are always going to be some utility methods
which cannot be cleanly attached to some class or other and then it's really
more about "listing" them.

The bottom line of this is really: a) Think *very* carefully about the
classes (concepts) you want to introduce for utility methods. b) Provide a
(couple of) generic places where utility methods can live. Right now we have
two such places - SystemDictionary which holds most of the "environment
related" utility methods and Utilities which holds most of the rest.
Introducing a hundred new classes all of which have one or two methods just
so that they are NOT in some place isn't very good design either. IMO at
least.

Cheers,
  - Andreas