Hi Nathanael,

>So, let's try. I agree with Stef that SystemDictionary is really a 
>mess and that it sould be cleaned. What I bothers me the most about 
>it is the fact that we use it not only for different 'functional 
>purposes' (e.g., VM statistics, graphical support, changesets) but 
>even for two different 'conceptual purposes', namely as a subclass of 
>IdentityDictionary and a collection of utility methods.

I have thought the same about separating the dictionary of classnames 
and the system utilities. 

>Now, we come to the last issue, which is the question of whether the
>utility class B should be split into multiple utility classes B1, ...,
>Bn, which each contain some methods that functionally and conceptually
>belong together. As far as I understand, this is the only issue where
>people really disagree.
>
>Well, here is what I think:
>
>First, I need to say that this does not seem the most critical issue 
>of the KCP to me. As far as my experience from doing the Traits
>implementation goes, splitting up the class SystemDictionary into A 
>and B and getting rid of all the code duplication (and other 
>deficiencies in B such as methods that don't even belong there and/or 
>will eventually be duplicated in other classes) is much more 
>important. 

Would you than accept it, if we leave B as a single class, name it e.g.
System and put its single instance into the global variable Smalltalk?

Two reasons to do so:

Because most methods are really 'functions', different classes as 
'function-holders' have only the same functionality as method-
categories, nothing more. But the programmer has to remember not only 
the selectors but different objects as receivers - more complicated, 
and something new to learn. 

These new different classes are in fact one virtual object - the 
medium which brings 'Smalltalk the experience' to you, to which you 
interactively and programmatically talk, which you want to query about 
its abilities and needs and resources, which you are manipulating. So 
it should be fine to have one single class for this 'object' in a 
variable with a single name: Smalltalk. 

regards,
Martin

PS: The cleaning of B of which you talked ( duplicate methods, methods 
clearly belonging to existing classes etc ) is of course useful.