> I think generally about class names and responsibility 
> re-distributions,
> changing them after they are included in the image is something we
> should really really avoid, because we can deprecate methods, but
> deprecating whole classes is depressing. This also affects code beyond
> the image (packages).

agree

>
> So I think in the future to save you the trouble, it would be good to
> decide what responsibilities to move to what classes and what to call
> them before making a lot of changes - especially if the name change
> isn't immediate.

The quest for the SmalltalkImage started more than 6 months ago where 
we discussed
with tim. And when he was saying that VM was not the name. and that we 
do not need two classes (which I still believe but I do not really 
care.) My goal is to save SystemDictionary right now.

> Anyway, for this case, why are all those things in the same object?
> here's an alternative split/naming.

I argued about that long time ago and I gave up and I do not care at 
the end.
You know the argument Smalltalk is easy to remember, it is not my 
busyness. So for now
I have no problem having another big but clean class.

>
> There are some things there that are local to a SmalltalkSession
>> VM parameter, modules () image names, saves changes,
>
> Some which are parts of the VMInterface
>> wm profiling, gc,
>
> And others which are specific mechanisms that seem to fit in their own
> classes -
>> version, memory hogs, startup item list,
>
> Does this split/naming make sense?

Do Not Care :)
Do not have the energy to fight for that.

>
> Daniel
>
> ducasse <ducasse at iam.unibe.ch> wrote:
>>> I don't recall that you mentioned a Squeak global, but I may be 
>>> wrong.
>>
>> Choice 3
>>> Can you give a precise reference?
>>
>> Re: For Smalltalk, SmalltalkImage and the rest
>>
>>
>>> anyway, nobody can promise you'll
>>> always get immediate notice.
>>
>> I know but I shout for the principle :)
>> Note that this is boring to have to update all the other files too and
>> the comments which RB does not treat.
>>>
>>> Talking about renames, are you using the RB already? (not that it 
>>> helps
>>> with the comments, but there a textual search replace might do the
>>> trick)
>>
>> Not yet I should confess. I will really start because I'm fed up the
>> problem is that if RB would be in image this
>> woudl be much simple now I have to pay attention if a change is in RB
>> or not.
>>
>>> On another angle - if the object's responsibilities is more than
>>> SmalltalkImage says, don't start renaming yet - tell us what
>>> responsibilities it will have, and we'll find a good name. If we 
>>> can't
>>> find a good name, maybe the object is becoming too big.
>>
>> VM parameter, wm profiling, modules, image names, gc, modules,
>> saves changes, version, memory hogs, startup item list, for the most
>> important ones.
>>
>>
>> I suggest to move the changes in because after one renaming is easier
>> that to edit
>> all the changesets.
>>
>> So how do we proceed? for me all the KCP changes that are not included
>> may rot and
>> I would like to avoid that.
>>
>> Stef
>>
>>>
>>> Daniel
>>>
>>> ducasse <ducasse at iam.unibe.ch> wrote:
>>>> Hi daniel
>>>>
>>>> I agree with you but why did you tell it before?  I spent more than 
>>>> 2
>>>> hours fixing all the SmalltalkImage uniqueInstance into Squeak.
>>>> (I do not like SmalltalkImage because this is more than that you 
>>>> will
>>>> see when we will have all the GC related methods inside).
>>>>
>>>> Now I ready to change again but people should shout now!!!!!!!!!
>>>> because I will do it twice. I raised the question before and got two
>>>> answers. so what.
>>>>
>>>> Stef
>>>>
>>>>
>>>>
>>>> On Jeudi, oct 2, 2003, at 15:45 Europe/Zurich, Daniel Vainsencher
>>>> wrote:
>>>>
>>>>>
>>>>> First, about the refactoring itself, and the responsibilities moved
>>>>> to
>>>>> SystemVersion and SmalltalkImage, I think the change is good. I 
>>>>> want
>>>>> to
>>>>> raise some naming issues, though -
>>>>>
>>>>> IIUC, the new global Squeak is defined to reference 
>>>>> SmalltalkImage's
>>>>> sole instance. First, I'm not sure that's a good use for the name.
>>>>> The
>>>>> functions therein are esoteric for most people, and Squeak is a 
>>>>> very
>>>>> non
>>>>> specific name for it.
>>>>>
>>>>> Second, the code, change set comment and deprecation comments vary 
>>>>> on
>>>>> whether to reference this instance as
>>>>> - SmalltalkImage uniqueInstance
>>>>> - SmalltalkImage current
>>>>> - Squeak
>>>>>
>>>>> Whatever we pick, it better be consistent. I personally would 
>>>>> prefer
>>>>> the
>>>>> "current" variant. About using Squeak - I think Globals should be
>>>>> reserved to commonly accessed concepts. SmalltalkImage doesn't seem
>>>>> to
>>>>> be one, so I'd be lazy about giving it the name. These things are
>>>>> easier
>>>>> to give than to take away...
>>>>>
>>>>> Daniel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> < I'm a bug-fixing machine! >
>>>>>
>>>>> This post brought to you by the BugFixArchiveViewer, a handy tool
>>>>> that
>>>>> makes it easy to comment on proposed fixes and enhancements for
>>>>> Squeak.
>>>>> For more information, check out the Web page for the
>>>>> BugFixArchiveViewer
>>>>> project: http://minnow.cc.gatech.edu/squeak/3214
>>>>>
>>>>> < I'm a bug-fixing machine! >
>>>>>
>>>
>