Generalized Object Modules Design
Bert Freudenberg
bert at isg.cs.uni-magdeburg.de
Thu Mar 7 08:48:51 UTC 2002
On Wed, 6 Mar 2002, Lex Spoon wrote:
> Suppose I have the following changesets in my image:
>
> URL
> HTML-Tokenizer
> HTML-Parser
> HTML-Formatter
>
> I'm mainly working on the parser, so the current changeset is
> HTML-Parser. However, I stumble across a bug somewhere in my code (I
> think that has happened once or twice. Please, bear with me.). After
> hitting implementors-of a few times, I'm looking at a blue message list
> window pointing at Url>>fragment. Voila, this is it, just change one
> line of code....
>
> Unfortunately the change will end up in the Parser changeset, even
> though it belongs in URL. Why can't the system be set up to put all Url
> changes into the URL changeset?
Who says it can't? I used to work with just this type of changeset
management and it was incredibly useful:
http://www.heeg.de/AppMan18/userGuide.htm
> Changeset-per-browser doesn't really help here. All my changesets and
> message windows and such will be assigned to the Parser changeset. Even
> if I have a URL browser floating around, I would have to dig through
> that browser to find the right method again, and that's even more work
> than switching the active changeset.
>
> It seems like the system could easily guess which changeset to put
> something in, most of the time. The big question, it seems, is whether
> there is a scheme that's so complicated to configure that it beats the
> point....
It just asks you in which changeset the method should live. And you can
still move around stuff, just like teh double change sorter.
-- Bert
More information about the Squeak-dev
mailing list
|