At 9:11 PM +0100 12/17/07, Erik Huelsmann wrote:
>On Dec 17, 2007 7:20 PM, Jack Repenning <jrepenning@collab.net> wrote:
>> On Dec 17, 2007, at 8:36 AM, David Glasser wrote:
> >
>> > This means that authors of a program
>> > like svnmerge.py which invoke "svn" with many different subcommands
> > > need to carefully figure out which subcommands take --non-interactive
>> > and which do not;
>>
>> As a writer of scripts that invoke svn myself, I'm baffled here. Does
>> not svnmerge.py also have to "carefully figure out which subcommands"
>> take two arguments (as diff), or which can only use an URL, or which
>> need a "--force", or myriad other matters not so susceptible to this
>> blanket-acceptance approach?
>
>Right, but don't 2-argument functions usually remain 2-argument? Or,
>at least, a 2-argument version will still be supported, even if we
>relax requirements to a 1-argument version where the second argument
>is assumed, or a 3-argument version is also introduced.
That would be consistent with most API evolution that I've seen:
It's permissible to add forms that would have been illegal in
previous versions as long as previously legal code remains legal
(with identical functionality).
> > > and worse still, if in a future version we suddenly
>> > come up with a new interactive mode in a subcommand that didn't take
>> > --non-interactive before, the script will suddenly stop working.
>>
>> That sounds like an API change to me, and "presumptively a bug," as
>> someone or other opined in IRC just Friday.
>
>So, how do we react to that, then, if a command would suddenly become
>interactive? You propose to keep 'svn merge' non-interactive and
>implement a (now interactive) 'svn merge2'? That - in my eyes - is
>even a bigger UI wart (although a consistent API).
For common options, I think it's important to distinguish between
_extraneous_ information and _conflicting_ information -- conflicting
information becomes a constraint and should generate a runtime
exception.
For instance, providing authentication credentials to a command that
does not need to authenticate is extraneous information. What if the
command could have an authenticated form in the future?
--non-interactive is a constraint -- it _should_ apply to all
commands and generate a runtime exception if the command attempts to
interact with the user (conflicting information), orthogonal to
wether the command changes its operation based on the option.
-v [--verbose] should be supported for all commands but might be
extraneous if the command produces no output.
The argument was made that script writers are a small percentage of
the user base (and therefore are presumably unimportant to support).
I would ask what harm does making life easier for scripters by making
the command set more regular do to "normal users"?
About the only argument(s) I can come up with against defining
standard options are:
1) Consumes a switch that could be used for another purpose
2) Documentation clutter
3) Masking a programmer error
4) Makes it harder for studley power users to demonstrate their
prowess in memorizing obscure, inconsistend infromation. :-)
One can question wether reusing common switches (-v) is a good idea
in any case.
The second could be addressed by just making a note of which common
arguments are/aren't supported by a command and and which are
accepted but ignored -- this might actually improve readability of
the documentation.
I have no objection to a --pedantic (or --trivia-test), that makes
providing extraenous information a warning or error, but the utility
of defining a common set of options for the ease and robustness of
script writers seems like a "good thing".
(You could argue that this should be --permissive for use by
scripters and/or which should be the default)
Cheers,
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 17 22:49:34 2007