KCP call for idea, experience
ducasse at iam.unibe.ch
Mon Apr 14 07:41:22 UTC 2003
>> I would like to have your point of view on how to clean
> OK; here is a rather extreme view on a possible approach.
> 'Smalltalk' the global variable that holds all global variables should
> be an Environment (or subclass thereof) and SystemDictionary should not
> exist. All the methods not directly to do with the use of 'Smalltalk'
> the default or root Environment belong somewhere else.
> Addressing some specific pints:-
>> Now the question SystemDictionary has far too much responsibilities as
>> we can see:
>> I tried to make already some conceptual groups
>> - browsing (easy we can move that to systemNavigation)
> What would be wrong with moving them to Browser? Probably class side.
> "Browser onAllMethodsWhere:[:cm| cm primitive = 117 and:[cm literals
> second == 'FilePlugin']] " for example instead of "Smalltalk
The idea of SystemNavigation is that all the tools can then call these
When I read the comments of the methods I moved from Behavior to
SystemNavigation, I saw that part of the motivation to put them there
was so that multiple clients could reuse them.
>> - namespace fonctionality (this is clearly the responsibility of
>> SystemDictionary so this should stay there)
> See above.
>> - benchmarks (someone proposed to move the benchmarks into a separate
>> class, it is correct or did I get hallucinations?)
> Moved to MacroBenchmarks by Markus D and Benchmarks (for the old Green
> Book benchmarks) by me. Could do with merging I suggest.
Yes I added that on the wiki page
>> - time ??
> Time class
>> - space profiler (-> Profiler class ?)
>> - shrink scripts (May be this was for shrinking that someone proposed
>> to move the them into a separate class, it is correct ?)
> Will cease to be needed seen, if all goes to plan.
>> - sources and changes
> Make a new class. SourceFileManager is a horrible but descriptive name.
>> - VM support such a isLittleEndian
> SystemDescription would be a good place for all the stuff relating to
> what platform is in use, what keyboard mapping, mouse button reversal,
> endianness, colour of reset button etc.
>> - snapshot functionality such as addToShutDown
>> - profiling (could go with VM support)
>> - Pluggins list access
>> - special Object and GC (in VW there are I guess in ObjectMemory the
>> class that represent the memory)
>> - platformInformation
>> - VM parameters
>> - memorySpace
>> - power disabling
> (There is already a PowerManagement class this could go to )
>>> - screen management -> Display
>> - all kind of other not related information such as itsyVoltage...
> Could all go in SystemDescription without seeming too awful. Except
> possibly the startup & shutdown lists.
>> I imagine easily that the VM has some knowledge that some methods are
>> really defined
>> on this class.
> As Andreas said, no problems. None of the primitives have a clue about
> Smalltalk or SystemDictionary. Excpet very indirectly the
> specialObjectsArray stuff but nothing to worry about there.
Tim I will give a try and if you want (I hope) I would like to have
feedback on that.
> Prof. Dr. Stéphane DUCASSE
"if you knew today was your last day on earth, what would you do
different? ... especially if,
by doing something different, today might not be your last day on
"The best way to predict the future is to invent it..." Alan Kay.
Open Source Smalltalks: http://www.squeak.org,
Free books for Universities at
Free Online Book at
More information about the Squeak-dev