Stephane Ducasse <ducasse at iam.unibe.ch> wrote:

> hi all
> 
> I would like to have your point of view on how to clean 
> SystemDictionary.
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' as
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
browseAllSelect:[:cm......"

> 	- 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.
> 
> 	- 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
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
CCCP:> format CCCP: /u