Hi,
I've thought of the whole stuff this week-end and IMHO, it would be nice
to use functor for this purpose. Indeed by using unary predicates,
functions and procedures, it would be quite easy to specify the behaviour
we discussed lately.
For example, in OptionBuilder:
* withPostProcess(UnaryFunction f)
When calling line.optionValue(String s), return
f.evaluate(line.optionValue s) instead. May be used to convert the
argument value to numeric value and directly return an Integer instance...
* withPostProcess(UnaryProcedure p)
Upon parsing, if the whole parsing process succeeds, and before returning
the resulting command line, the parser will apply for each option the
post-processing procedures that have been specified. Thus it would allow
to automatically set a system property when a given option is set.
* withPredicate(UnaryPredicate p)
While parsing, for each of the options where one or more predicate has
been associated, the predicates are tested for each value and a false
return condition would have the parser throwing a ParseException embedding
the predicate name. Useful to have the parser automatically perform type
checking, or to test if the specified filename represents an existing
file.
* withPostPredicate(UnaryPredicate p)
Upon parsing, if the whole parsing process succeeds, and before evaluating
post-processing procedures, test the post-processing predicates associated
with each option. Thus it would allow to specify the following behaviour
we discussed: "the --overwrite option is only relevant if an output file
is specified with --output".
Then we could have commonly used predicates, functions and procedures
already implemented in the CLI package. For example:
IsExistingFilePredicate()
IsReadableFilePredicate()
IsWritableFilePredicate()
IsIntegerPredicate()
NeedsOptionSetPostPredicate(Option o);
MapToSystemPropertiesProcedure()
MapToSystemPropertiesProcedure(String prefix)
GetValueAsIntegerFunction()
Regarding the functor dependency, it could be easy to have the relevant
methods throw an OperationNotSupportedException (which is a
RuntimeException and thus does not need to be catched) when the functor
package is not present in the classpath. This way, functor becomes
mandatory only when building CLI (and obvioulsy when the application that
makes use of CLI needs the features I described in this mail).
What do you think of it ?
Herve
On Thu, 6 Mar 2003, Herve Quiroz wrote:
>
>
> On Thu, 6 Mar 2003, John Keyes wrote:
>
> > > Now speaking of something not closely related, I remember reading on this
> > > list something about OptionGroup that would allow rules like "the
> > > --overwrite option is only relevant if an output file is specified with
> > > --output". Is this planned (or already done) for CLI-2 ? Because it could
> > > possibly get easy with the functor/predicate stuff we discussed.
> > This isn't really an OptionGroup issue. Its more general. It should
> > be possible using child options. So --output would have child options,
> > and when the --output has been handled parse the remaining tokens
> > using its child options. CLI-2 doesn't exist yet and may not depending
> > on whether it is voted in. At the moment its an experiment that aims to
> > improve on the work done for 1.0. So all of this feedback is great as
> > it shows that people had problems with 1.0 and would like to see them
> > resolved.
>
> Therefore here is another interesting feature:
>
> I used to use a Configuration object (from jakarta-commons-configuration)
> to centralize all preferences in my projects. Hence a lot of command line
> options need to be propagated to this configuration instance.
>
> // Initialize configuration with some default values...
> // Then parse the command line.
>
> if (commnadLine.hasOption("verbose")
> configuration.setProperty("domain.myapp.verbose","true");
>
> if (commandLine.hasOption("port")
> configuration.setProperty("...port",commandLine.optionValue("port"));
>
> It would be nice to specify such a behaviour within the option builder.
> And using the functor stuff we discussed, that could stay quite simple.
>
> For example:
>
> OptionBuilder.withPostProcess(new ConfigurationMapperFunctor(config))...
> ...withLongName("argname").create();
>
> I don't know if that makes sense (I am about to leave work...) so I will
> re-think of it tonight and tell you tomorrow if I got something
> interesting (and clear) enough. ;)
>
> Herve
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
