What I like with nathanael is that he is so right.

Stef

PS: I was really trying to put all the changes, vm and other image, 
modules related methods in one class but this is ending up to be again 
quite big. So may be having two classes instead f one will be the way 
to go.



On Monday, June 16, 2003, at 10:06 AM, Nathanael Schärli wrote:

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