[darcs-users] "replace" patch type (was: bug or inconsistency in darcs replace)

Kevin Smith 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.

Ah, right.

> 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 mailing list