Hi tim

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

Agree

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

The idea of SystemNavigation is that all the tools can then call these 
functions.
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.

Stef







> Prof. Dr. Stéphane DUCASSE
http://www.iam.unibe.ch/~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 
earth" Calvin&Hobbes

"The best way to predict the future is to invent it..." Alan Kay.

Open Source Smalltalks: http://www.squeak.org, 
http://www.gnu.org/software/smalltalk/smalltalk.html
Free books for Universities at 
http://www.esug.org/sponsoring/promotionProgram.html
Free Online Book at 
http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html