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

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. BTW, if we had a smarter deprecation protocol, it could
be automatically refactored by the RB, like

self deprecatedNewMethodIs: SmalltalkImage >> #vmPath.

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

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?

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