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 email...
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: argumentBuilder.withDefault(Object)
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!
Rob
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
