commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Oxspring <>
Subject Re: [CLI] default values
Date Mon, 16 Feb 2004 23:21:35 GMT
John Keyes wrote:

> One of the failing unit tests on the ROXSPRING branch was the
> testWithOption method on CommandLineDefaultsTests.  The reason
> it failed was the default value set during Option construction
> was not accessible to CommandLine.getValue.  So to make this
> information accessible I propose we add a getArgument method to
> Parent and getDefaults to Argument.  To see if any default
> during construction we simply do:
>   if (option instanceof Parent) {
>     Argument arg = ((Parent) option).getArgument();
>     List defaults = arg.getDefaults();
>   }
> Did you have a different idea about how to resolve this Rob?

Yeah - I had half a plan last week but didn't get around to sending the 

My main reason for writing the CommandLineDefaultsTest was that I felt 
the combination of 4 different ways to specify defaults was confusing.  
Last week I thought we could reduce this to 3 but tonight I'm thinking 
that 2 might be a possibility.  Here are the 4 sources as they stand (or 
as I understand them):

A. Specified at interrogation time (using the overloaded accessor 
methods in CommandLine)
B. CommandLine chains using push/set/addDefaultCommandLine(..)
C. Defaults instances from properties and preferences
D. Specified at option construction time: 

A is a very simple and intuitive way for people to get the values they 
expect without involving themselves with the alternative systems.  I'd 
like to keep this mechanism as it is.

I think B & C should be combined into a single mechanism.  They both 
appear to be tackling the same basic problem - applying defaults 
independantly of interrogation and option construction.  B has two main 
advantages that I can see; the first is that by using CommandLine as the 
vehicle it opens the door to supplying defaults for non-arguments 
(on/off for switches and potentially "presence" for simple Command / 
DefaultOpitions).  B's second advantage is that the chain of objects 
allows a customisable precedence order to be set for defaults (think 
user vs project vs system vs site defaults).  Of course the huige 
advantage of C is that implementations exist for Properties and 
Preferences.  I propose we build a new "DefaultingCommandLine" 
implementation of CommandLine that simply manages and delegates to a 
List of CommandLine instances; this would mean that we can simplify the 
CommandLine interface to not have the add/set/pushDefaultCommandLine 
methods.  Then we convert the Defaults implementations into simple 
CommandLine implementations, supply defaults for non-arguments in 2.1 or 
later.  This would allow a more flexible system with at least the 
current functionality and less overall complexity (IMO).

If we go the route mentioned above then fitting in the construction-time 
defaults might be a little difficult.  An approach that occured to me 
tonight is that we could add a new method to Option along the lines of 
defaults(WriteableCommandLine) that would implement the same structure 
walking as process(..) but us used simply to build a 
WriteableCommandLine of the construction time defaults.

These in combination allow the user's experience of defaults to be 
reduced to three mechanisms A, B/C, D while the code would be pretty 
much simplified to two A, B/C/D.

Make sense? over ambitious? or plain missing the point? - thoughts welcome!


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message