Hi tim

we discussed that point when noury was here. And this is true that we 
could merge that into a
System class with all the mess related to the image GC, changes, 
sources, startuplist......
I passed the message to the kcp list and we will see. I'm not convinced 
that a class with accessing VM parameter, modules, vm profiling, and 
all the stuff I grouped plus all the image related behavior will be 
good at the end. System sounds too much like Stuff, Bunch, Utilities if 
you see what I think.

I do not understand why having two small classes is not better that a 
big fat one. Especially because we are trying
to create coherent abstractions.

About the general purpose, note that we believe that having class with 
well identified responsibility is the best way to create abstraction. 
We believe that after others can build on them, enrich them. The 
process is important. I saw that we creating SpaceTally from 
spaceTallyOn: and related methods.

I do not know enough to know where to put specialObjects alex told me 
that the special objects
are needed by the VM. So VM was certainly not a good name after 
thinking about it.

For the class side of life, we have one strong opinion about what 
should be put on class side: class
behavior! Using class methods to represent instance behavior is a sick 
behavior on the long term.
Sometimes I do that for my own code because I'm lazy but here this is 
the code that a lot of people
will read and more important learn from it. I think that this later 
aspect is really important (or
I missed the idea promoted by alan so that everybody should be 
understand the complete system and learn from it).

So this is why we do not want to have class methods that are not about 
class behavior. If OOP would propose better ways to do it we will use 
it.

You are free to disagree with class side.

Stef


On Saturday, June 28, 2003, at 10:48 PM, Tim Rowledge wrote:

> Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
>
>> Hi
>>
>> I'm extracting the class VM from SystemDictionary. It is attached for
>> review and feedback.
>>
>> VM has right now the following methods:
>>
>>   a Set(#endianness #isLittleEndian #listBuiltinModules
>> #specialObjectsArray #setPlatformPreferences #stopProfiling
>> #getSystemAttribute: #quitPrimitive #externalObjects
>> #vmParameterAt:put: #unregisterExternalObject:
>> #unbindExternalPrimitives #specialSelectors #listLoadedModules
>> #compactClassesArray #profile: #dumpProfile #version #platformName
>> #platformSubtype #isBigEndian #recreateSpecialObjectsArray
>> #startProfiling #osVersion #registerExternalObject: #vmParameterAt:
>> #specialNargsAt: #getVMParameters #clearExternalObjects
>> #specialSelectorAt: #unloadModule: #clearProfile #specialSelectorSize
>> #listLoadedModule: #listBuiltinModule: #extraVMMemory
>> #hasSpecialSelector:ifTrueSetByte: #extraVMMemory:)
>>
>> We planned to have finally a class responsible for image management
>> (GC, sources files, ...all the rest)
> I'm sorry to say that I really don't like the way some of this is 
> going.
> Certainly cleaning up SystemDictionary is a Good Thing but I'm having
> trouble swallowing splitting code into so many places on a tenuous
> basis.
>
> Many of the items in the list above are not particularly to do with
> the VM anyway - they are related to the _system_ as a whole.
>
> In particular (for an example) #specialSelectors is nothing to do with
> the VM - in fact the 'SpecialSelectors' object seems t be pretty much
> unused and responsibility for the special selectors is delegated to
> the specialObjectsArray. Oh, and an instvar with a capital letter is a
> capital crime....
> #hasSpecialSelector:ifTrueSetByte: certainly doesn't belong anywhere
> near VM stuff; it's more plausibly something to do with
> SystemNavigation.
>
> No, I'd claim that a class named something relatively simple
> like 'System' is the place for most of this, along with many of the
> things I've seen in discussions of 'Image'. And again, I'd go for
> class-side code since there is really only a single System around at 
> any
> one time.
>
>
> tim
> --
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> Useful random insult:- Cursor's flashing but there's no response.
>