On 12/2/05, Michael Sinz <Michael.Sinz@sinz.org> wrote:
> How does making the heuristics actually figure out the "DWIM" action make
> script writing harder?
Well, the general principle is that, the more complicated the rules a
command follows in deciding what to do with its arguments, the harder
a script has to work to ensure it'll get a particular interpretation,
regardless of the arguments it's passing (which may have come from the
user).
The classic example is a script trying to change the name of a file to
something provided by the user. If there is already a file with the
given name, you'd like to get an error. But if there is a directory
of that name, then 'mv' will move the file *into* the directory, which
isn't what you wanted.
Does that principle apply in our case? If a script takes a list of
filenames in a working directory and tries to find local changes, then
if the user happens to pass two arguments, one of which is a URL (as a
mistake), then Subversion will go off and do a remote diff between the
first and second arguments, instead of comparing each file with its
base. Who knows what the script will do with that.
Sure, it's the responsibility of the script to check every filename
argument to see if it starts with some Subversion scheme (http:,
https:, svn:, svn+ssh), but really, who's going to bother, or even
remember, to do that?
Put another way, the problem with DWIM is that the behavior often
depends on the exact arguments, whereas scripts often pass the values
of variables or $(command substitutions). So which command you get
depends on the values of the parameters, which you don't have direct
control over.
Tendentious or not, that's my argument.
I think its weak point is that behavior like mv's has been acceptable
--- and convenient --- for millions of Unix users for decades, and the
script problems aren't something that you hear much about. Of course,
this is because the bugs get blamed on the scripts' authors, not on
the command; but I think that's misplaced.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 3 01:42:41 2005