[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: setprop vs. propset

From: Neels Hofmeyr <neels_at_elego.de>
Date: Sun, 24 Aug 2008 04:37:18 +0200

Stefan Sperling wrote:
> On Sat, Aug 23, 2008 at 09:18:10AM -0400, C. Michael Pilato wrote:
>> Stefan Sperling wrote:
>>> And while I agree that adding too many aliases for commands can
>>> lead to a confusing UI in the long term, I don't think that it
>>> will cause confusion in this particular case.
>> Let's face the facts, here: most of our commands have aliases for one of
>> two reasons:
>> * To match the name/alias of the similar CVS subcommand
>> * To provide a shorter thing to type for especially long subcommands

The second one could be paraphrased: "To make it easier to type a
subcommand". IMHO, `setprop' sits much better in my brain, to the degree
that it involuntarily turns `propset' around do `setprop'.

Once that's there, I'd expect `sp' to work as well.

I think the reason to accept these aliases is almost the same as the reason
why you can buy left-handed scissors. The UI should be easily usable.

It's a rather special case, which arises from common English, and
programming style of having "get" or "set" first in a function name, and
from people having used this so much that we are left-handed about it.

It also arises from the fact that the commands are not subdivided as in `svn
prop --set' (one could argue this one to favor propset, though).

...I guess we have all the bikeshed colors by now ;) Who decides?

Neels Hofmeyr -- elego Software Solutions GmbH
Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23458696  mobile: +49 177 2345869  fax: +49 30 23458695
http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelsreg: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194

Received on 2008-08-24 04:37:53 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.