I agree with Nathanael's post completely. 

I would love for KCP and MCP (and anyone else that feels for the goals
below) to focus on disconnecting bad references, because:
A. That would make the system easier to understand.
B. It would make things unloadable, therefore the system smaller, and
therefore more of A again.
C. I wrote a tool to help do this, and I'd like to get feedback on it!
:-)

Daniel

=?iso-8859-1?Q?Nathanael_Sch=E4rli?= <n.schaerli at gmx.net> wrote:
> 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
> > >
> >