[darcs-users] "replace" patch type (was: bug or inconsistency in darcs replace)
yarcs at qualitycode.com
Sat Mar 27 17:59:09 UTC 2004
David Roundy wrote:
> On Sat, Mar 27, 2004 at 09:21:17AM -0800, Kevin Smith wrote:
>>replace --force [a-zA-Z] oldtoken newtoken ./foo.c
> No, that wouldn't work, since it wouldn't be invertible.
> As I recall (correct me if I'm wrong), your concerns with replace stem from
> the difficulties that could arise when replacing a "token" that could have
> different meanings in different contexts, and where you only want to rename
> one of those items (e.g. if two classes each have a method with the same
> name, and you only want to rename that method in one of the classes.
That is one concern, but not my biggest one. That could be helped by
allowing an optional line number range constraint. I can imagine a gui
tool that would construct an appropriate darcs replace command within a
single method, or class.
> On the other hand, if you have a practice of giving each function a
> different name, except when they inherently always should have the same
> name (e.g. operator+), then replace won't be prone to the aforementioned
> problem (accidentally replacing another function having the same name).
It is probably worse when renaming variables. Local variables or
parameters within each method often use ordinary names that are not
distinct. Again, a line number constraint would help.
A bigger problem is that a replace in class Foo of member Bar cannot
distinguish between references to aFoo.Bar and aNonFoo.Bar. If
aNonFoo.Bar actually exists, it might be difficult to detect this error.
Not all projects have test suites, unfortunately.
But probably my biggest concern is that the change extends unbounded
through time and space. A "replace" that does exactly what I want in my
repo today might do something unexpected and unwanted in a different
repo, or at some point in the future.
You consider that a "feature", because it will automatically "fix" uses
of the old name in other code. I consider it a problem, because it is
too unpredictable and may break code in strange ways.
It is a powerful tool, but a dangerous one. I am concerned about handing
this loaded gun to everyone without proper warnings, training, and
safety mechanisms. RCS systems should (IMHO) do whatever they can to
keep your code safe and avoid surprising you.
In short, I put lower value on its benefits than you, and worry more
about its costs. For me, it fails to break even on the benefit/cost ratio.
I would feel better if we could instead (later) offer more sophisticated
refactoring patch types for specific languages. For statically typed
languages, these could be far safer and more effective.
More information about the darcs-users