dway at riskmetrics.com
Mon Apr 7 16:15:22 CEST 2003
Daniel Vainsencher wrote:
> I agree that we should make sure removal of a package doesn't break
> either it or other stuff in the image.
> I don't know whether there's a point in separating the refactorings from
> the removal package. After all, the removal package is supposed to get
> rolled into the updatestream.
> The Celeste removal does the refactorings required and then removes the
> package, which seemed reasonable to me at the time. If someone thinks
> this is a problem, I don't mind reworking it so refactorings and
> removals are separate.
Actually, that's not a big deal... for some reason I was thinking that we were
encouraging separate refactoring packages.
I guess the more important thing is that we should encourange the resulting
maintained packages to not overwrite methods if possible. This will mean that
the pre-removal refactoring did its job. In practice, though, this may not
always be possible.
> Other quality criteria - we should encourage package maintainers to
> never override code, but we can't enforce it. Right now, there isn't
> even a warning when loading a package that overrides code. We should
> provide the tool support first, start pushin the rule later.
Right. By tool support, you mean things like adding the warning?
More information about the Squeakfoundation