Martin,

> 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?

Well, I'm not against having a class called 'System' or 'Utilities', but
I think that we should definitely try to identify some group of
'functions' that obviously/intuitively belong together and can therefore
be put into a class Bi without making the system harder to
understand/use/extend.

> 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. 

I don't agree to this. Method-categories are purely descriptive, whereas
classes are semantic entities that establish some form of namespaces. As
an concrete exmaple, take the functions #fullNameForImage: and
#fullNameForChanges:. If you put them into different method-categories
of a class 'System', you have to avoid name clashed by choosing a long
name. 

However, if you put them into two classes 'Image' and 'Changes', then
you can simply use the selector #fullName for both of them! The same
thing holds for many other selectors in SystemDictionary such as
#listLoadedModules, #listBuiltinModules, etc.

So, there obviosuly *is* a very significant difference!


> But the programmer has to remember not only 
> the selectors but different objects as receivers - more complicated, 
> and something new to learn. 

How is remembering an intuitive receiver any worse than remembering a
very long name that simply contains the receiver in the name?

Are you really saying that:

- "System fullNameForChanges:" is simpler than "Changes fullName:"
- "System fullNameForImage:" is simpler than "Image fullName:"
- "System listBuiltinModules" is simplar than: "BuiltinModules list"
- "System listLoadedModules" is simplar than: "LoadedModules list"
- etc.

If yes, then I'm really curious why, because as you can see the
alternatives are often even shorter. For me, the opposite is true. I
like short *polymorphic* selectors much better than long names that have
the receiver artificially coded into the name just to make clear what
happened. Not only does this make it hard to avoid name clashes, but it
also does not allow real OO programming! With the second approach, you
can for example write a method

addModulesToMenu: modules
	...
	modules list do: [:each |
	...

And you can invoke this method for both BuiltinModules and
LoadedModules. This would not be possible with the first approach. So,
why do you not want to take advantage of OO programming here? Why do you
like procedural programming better?


> 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. 

Even with the new approach, you can still see all these classes as one
virtual object. As you know, objects/classes can be built with
aggregation and if it is important to you, we can design it so that you
can type:

- "Smalltalk image" instead of "Image"
- "Smalltalk changes" instead of Changes"
- etc.

The difference between this approach and what you suggested is not that
with this approach there is no virtual object for Smalltalk anymore. It
is just that the virtual object is structured! And again, I truly
believe that a intuitive/reasonable structuring is better than no
structuring. Especially when we talk about nearly 300  functions as in
SystemDictionary!

Nathanael


> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Martin Wirblat
> Sent: Donnerstag, 12. Juni 2003 23:18
> To: Squeak
> Subject: RE: [KCP] SystemDictionary cleaning: Comments and design
> 
> 
> 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. 
> 
>