Hi,

I just read this whole thread and it seems to me that it should be
possible to find a solution everyone is happy with.

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.

For a programmer that does not know this, this is *really* weird and
confusing. Just imagine that someone wants to learn about the ST
collection classes and therefore browses the different Dictionary
classes. After browsing IdentityDictionary, he will eventually see the
subclass SystemDictionary and all its methods such as #abandonSources,
#aboutThisSystem, etc. Being in the context of collection classes (which
typically have methods such as #do:, #detect:, #add:, etc.) this really
does not make any sense, and it will take him some time to understand
why these methods are actually there.

Therefore, I think that in a first step, we should seperate these two
*conceptual* roles of SystemDictionary, which means that there should be
a class A which can be instantiated in order to create a namespace
(which is essentially just a collection), and a class B which serves as
a holder of utility methods. This has the following advantages:

- Class A has a clear conceptual purpose: It is a subclass of
IdentityDictionary and therefore essentially a collection.
- Class B has a clear conceptual purpose: It is a holder of utility
methods.
- Everyone looking at class A can easily understand its purpose, and all
the methods make sense in the context of  this class being a sort of
dictionary.
- Everyone looking at class B can easily understand its purpose, it is
just a collection of utility methods.

Does anyone disagree with me on this?


Once this is done, we can now go to the second step and take a look at
the class B, which contains the utility methods that were previously in
the class SystemDictionary.

Also regarding this class, I see essentially two issues that should be
addressed: First, there are/were several methods that contained code
duplication and there are also some other issues (e.g., having utility
methods that actually belong into a class!) that need/needed to be
fixed. Second, this class clearly contains a lot of methods that are
both functionally and conceptually independent and it would therefore be
possible to factor some of them out.

Regarding the first issue, I think that everyone agrees that code
duplication (and some other limitations) should be eliminated, and as
far as I know, a lot of this work has already been done without
generating too much disagreement on the list. During the coding of the
Traits prototype, this part was what frustrated me most with the class
'SystemDictionary' and I'm really happy that everyone agreed that this
needs/needed to be done!

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.

For the rest, I pretty much agree with Andreas/Stef (it may sound
strange, but I actually think their positions are not that far away from
each other!): I think that trying to identify a few class Bi with a
*intuitive name* and *clear/obvious* responsibilities is great and we
should do so. However, it is ***absolutely*** important that we make
sure that the utility methods are as easily findable as they are before.
For short, I think that a intuitive (and not too extreme/fine-grained)
and clear grouping is better than no grouping, but a non-intuitive
grouping is worse than no grouping. And why not following Andreas'
suggestion and make a class Utility for all the methods that do not
clearly belong in one of the more specialiced utility classes and the
methods that are not classified yet? 

So, now please let me know whether you generally agree with what I wrote
here. If yes, then we just have to figure out how many class B1, ..., Bn
we want to create and how they should be called. I really think that
this should not be too hard! 

Nathanael



> -----Original Message-----
> From: Stephane Ducasse [mailto:ducasse at iam.unibe.ch]
> Sent: Donnerstag, 12. Juni 2003 12:06
> To: The general-purpose Squeak developers list
> Cc: Roel Wuyts; Alexandre Bergel; Nathanael Schärli
> Subject: Re: [KCP] SystemDictionary cleaning: Comments and design
> 
> 
> Thanks Tim for your feedback.
> 
> I do not think that this was a big effort. For us having
> SystemDictionary half-way cleaned or not at all is the same.
> 
> Look at VisualWorks or any other Smalltalk they have
> 
> - SourceManager default condenseChanges
> - ObjectMemory fullGarbageCollect
> 
> I do not really see the problem there. We will have another
> class Image 
> will 30 or 40 methods or more related to VM, Image, 
> startup... This is 
> a logical place. Else we should put everything in Object and 
> Smalltalk.
> 
> Stopping in the middle makes no point to us. In that case simply tell
> us and we stop
> all the KCP effort. Really. We have no problem everybody will 
> do it on 
> his corner and no problem.
> 
> Andreas you should really ask nathanael what he thinks about
> the kernel 
> and ask him to give you a non swiss answer. I'm not the only one that 
> think that we need to clean that.
> 
> Stef
> 
> 
> 
> On Thursday, June 12, 2003, at 01:31 AM, Tim Rowledge wrote:
> 
> > "Andreas Raab" <andreas.raab at gmx.de> wrote:
> >
> >> Ah, now here's an interesting point - I wasn't aware that your goal

> >> was to remove basically *all* methods from SystemDictionary.
> > I hadn't noticed that the aim was quite _that_ high either; I think
> > you
> > (Stef) might want to take this in smaller bites and rest a while in
> > between or you might go quite, quite mad. Seriously, you've been 
> > working
> > on this a long time and I suggest a rest and time to let 
> what has been
> > done settle down a bit. There are plenty of other areas needing
> > cleaning
> > up as well so don't obsess on just one.
> >
> >>  I'd still opt for a single
> >> generic utility class rather than twenty quite specific ones ;-)
> > If there is a case where it is really, definitely an obvious good
> > thing to have a class to represent some utility, then sure, 
> use it. I
> > have to agree with Andreas that for cases where there isn't
> anything
> > really clear, leave it in somewhere a bit more generic and
> make sure
> > it's commented as a temporary home. SystemDictionary is/was a real
> > mess but it was certainly easy to remember 'Smalltalk 
> garbageCollect'.
> > It might be quite a bit more annoying to have to learn that the new
> > system is 'Memory garbageCollect' but 'VMSupport save: foo andQuit: 
> > true'. Or is that 'Image save: foo andQuit: true'?
> >
> > tim
> > --
> > Tim Rowledge, tim at sumeru.stanford.edu,
> http://sumeru.stanford.edu/tim
> > Fractured Idiom:- VENI,
> VIDI, VISA - I came, I saw, I bought
> >
>