Stef, Andreas, and all

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

I absolutely agree with Stef on the importance of the KCP in general.
There really is a lot of mess in the kernel and it makes
improving/fixing/extending/changing the kernel really frustrating. 

At the same time, I also think that we have to make sure that we don't
get too much distracted with discussions/disagreements about 'details'.
For me, it is for example important that:

- The OO-kernel classes Object, Behavior, ClassDescription, Class,
Metaclass, etc. are clean. This means that they should have clean code
(in particular, no duplication) and at least as importantly a *clean
API*. Just have a look at the current "compiling API", there are tons of
methods such as #compile:, #compile:classified:,
#compile:classified:logChange:, #compile:classified:logChange:, which
have weird interactions and contain a few bits of duplicated code so
that it requires to change about 5 of them in order to reliably hook
into (or modify) the compilation process. Also, it really is annoying to
have references to 'CrazySpecializedMorph1' in these kernel classes!

- There is a clean distinction between kernel API and the UI. At the
moment (or at least before the KCP started), there was a lot of UI code
in the kernel classes and a lot of kernel code in the UI classes (such
as Browser), which made it really hard and frustrating to actually
extend either of them! Also classes lik ClassOrganizer are not
everything else but clean and extensible!

- There is no utility methods in SystemDictionary that are also
duplicated (or half-duplicated) in other classes, especially
Kernel-Classes. (In order to modify the 'browse-implementers',
'browse-senders', 'browse-local-senders', etc. for my Traits prototype I
had to change the same code at about 3 different places and I bet there
are still some places I forgot ;-)

- The fact that SystemDictionary is a collection class and a utility
class gave me some headache!

- etc.

Once stuff like this is all cleaned, I'm going to be so happy that I
don't care that much whether the utility methods that are now in
SystemDictionary are factored out into 3, 4 or 5 utility classes.
Therefore, I think we should not make this decision more important than
it is! Finally it is to a certain extent just a matter of taste  and
usage patterns, just like emails: Some people store their emails in only
10 folders wheres others would take 50 for the same purpose).

In particular, I think that we should not make the question about how
many utility classes we need to create into a "to be or not to be"
decision of KCP.

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