ChangeSorter: bug or feature?
dway at mailcan.com
Thu Jan 22 17:32:59 UTC 2004
Marcus Denker wrote:
> Am 22.01.2004 um 05:11 schrieb frits.swinkels:
>> I loaded a changeset from an outside source and did some work in it. I
>> then loaded a later changeset in which the outside source had done
>> some more work: I loaded this changeset under a different name. I wanted
>> to compare the two changesets in a DualChangeSorter. To my
>> surprise both panes showed the same new source code for methods of the
>> same name (and class), i.e. my work was wiped out.
> You have a wrong "mental modell" of what changesets are: They are just
> a name for a bunch of information about "these methods were changed on
> fileIn". So they allways show a view of the current state of the source.
That's sort of true, although as Fritz points out, the ChangeSet object
actually points to the right code (the right CompiledMethod, which then
knows its source pointer and can look up its source). So it's really
more the fault of the ChangeSorter that it only shows the current state
of the source.
But yeah, everyone uses the ChangeSorters to work with changesets, so
the current mental model is that changesets are just a list of methods
(etc.) that have changed. But I wouldn't say that this is a
particularly "good" mental model, in fact I'd consider it "bad". :-)
It would be interesting to "fix" the ChangeSorters so that they show the
original source from the changesets. It is true though that everyone
has gotten used to the ChangeSorters showing the current code, so there
would have to be some getting used to the new behavior.
More information about the Squeak-dev