[BUG]Class fileouts and changeset fileouts do not do the same

Tim Rowledge tim at sumeru.stanford.edu
Thu Apr 3 23:22:24 UTC 2003


I've just been badly bitten by the difference in behaviour between the
filing out of a changeset and a class.

If one files out a class which refers to a pool dictionary, the
dictionary is written out to the file.
{side problem - it asks the user if it should do that at fileout time
via a dialogue. this is marginally acceptable when the fileout is done
from the UI browser, totally unnacceptable when done via a doit}

If you then delete the class from the system and from the current
changeset, thus emulating the situation we will be facing a lot as code
is removed from the image and placed in packages, and then file it back
in one gets a changeset that would appear to encode the newness of the
class. Looks good so far.

Now file out the changeset and compare it to the class fileout. The pool
dictionary information is lost. If you then publish the changeset
to other people you now face a f*cked system.

In the case of the VM code removal/package something even odder
happenned somewhere in the process, B3dAcceleratorPlugin got the name of
it's pool dictionary ('B3DEngineConstants') changed to 'private'. No
other class involved, including those refering to the same pool, were
affected. When filing in the resultant package we get a dialogue asking
about initialising this new pool dictionary. This is wrong both because
it shouldn't be a new one and because like in the fileout above there
should not be any reliance upon a UI when filing in. It might be a
headless system for goodness sake..

What this means is that you can't file in a package as in packages made
by removing classes from the system), do some work on it and file it out
again and rely on it working correctly to re-filein. I really think some
sort of solution is quite important.

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: GSI: Garble Subsequent Instruction



More information about the Squeak-dev mailing list