Re: [Mono-dev] Lazy man´s Command Line Parser - Revisited
Rafael Teixeira
monoman at gmail.com
Thu Jan 12 09:37:14 EST 2006
Just a thing I have the impression you didn't understand about
Mono.GetOptions, everything is driven by Attributes, you only have to
inherit from the base class for some convenience things like the
automatic --help page. So in that regard your solution is nearly the
same thing.
Just and example:
-----------------
public class CatLikeOptions : Options
{
[Option("display TAB characters as ^I", 'T', "show-tabs")]
public bool ShowTabs;
[Option("display $ at end of each line", 'E', "show-ends")]
public bool ShowLineEnds;
[Option("use ^ and M- notation, except for LFD and TAB", 'v',
"show-nonp rinting")]
public bool ShowNonPrinting;
[Option("equivalent to -vE", 'e', null)]
public bool ShowLineEndsAndNonPrinting { set { ShowLineEnds =
ShowNonPri nting = value; } }
[Option("equivalent to -vT", 't', null)]
public bool ShowLineEndsAndTabs { set { ShowTabs =
ShowNonPrinting = val ue; } }
[Option("equivalent to -vET", 'A', "show-all")]
public bool showAll { set { ShowTabs = ShowLineEnds =
ShowNonPrinting = value; } }
[Option("number nonblank output lines", 'b', "number-nonblank")]
public bool NumberNonBlank;
[Option("number all output lines", 'n', "number")]
public bool NumberAllLines;
[Option("never more than one single blank line", 's', "squeeze-blank")]
public bool SqueezeBlankLines;
[Option("(ignored)", 'u', null)]
public bool Ignored;
[Option("output version information and exit", "version")]
public override WhatToDoNext DoAbout()
{
return base.DoAbout();
}
[Option("display this help and exit", "help")]
public override WhatToDoNext DoHelp()
{
return base.DoHelp();
}
[KillOption]
public override WhatToDoNext DoHelp2() { return WhatToDoNext.GoAhead; }
[KillOption]
public override WhatToDoNext DoUsage() { return WhatToDoNext.GoAhead; }
public CatLikeOptions(string[] args) : base(args) {}
protected override void InitializeOtherDefaults()
{
ParsingMode = OptionsParsingMode.Both |
OptionsParsingMode.GNU_D oubleDash;
BreakSingleDashManyLettersIntoManyOptions = true;
}
}
public class Driver {
public static int Main (string[] args)
{
CatLikeOptions options = new CatLikeOptions(args);
}
}
-----------------
If you run this program this way, you'll get:
-----------------
: mono mcat.exe --help
mcat 1.0.0.0 - (c)2005 Rafael Teixeira
Simulated cat-like program
Usage: mcat [options] [FILE]...
Concatenate FILE(s), or standard input, to standard output.
Options:
-A --show-all equivalent to -vET
-b --number-nonblank number nonblank output lines
-e equivalent to -vE
-E --show-ends display $ at end of each line
-n --number number all output lines
-s --squeeze-blank never more than one single blank line
-t equivalent to -vT
-T --show-tabs display TAB characters as ^I
-u (ignored)
-v --show-nonprinting use ^ and M- notation, except for LFD and TAB
--help display this help and exit
--version output version information and exit
With no FILE, or when FILE is -, read standard input.
Please report bugs to <rafaelteixeirabr at hotmail.com>
-----------------
So one have to really write less than 10 lines of 'imperative' code
to accomplish all that.
Nayway, thanks for your efforts and code, I think many programmers
will find it useful.
Regards,
On 1/12/06, Oscar Forero <oforero at novell.com> wrote:
> Hello,
>
> I discussed on IRC some points over my parser in the mono channel; more or less seems that the people do not want to
> know anything about it; and that many are happy with Mono.GetOptions.
>
> I still think mine is a superior solution, simple because it does a lot more that Mono.GetOptions; some of the negative
> comments and my answers to them:
>
> 1. Is not intuitive: Well following a naming convention and/or using Attributes is pretty easy, and should be at least
> as easy as extending a class.
>
> 2. It takes a lot of reading to know which parameters are supported: Well not really, if you want to know how to use a
> program, let it run with out command line and the help will tell you how it work, if you want to know which parameters
> are supported by a given operation go to the method. It is that easy, now i agree you can have a quicker overview over
> all the parameters in the application with Mono.GetOptions, but if you need to know which parameters are use in a given
> operation you have to read yourself through a lot of If s see what method is being call, go there and read some more.
>
> 3. It is not maintainable, if you need to add a parameter (the same) to many operations you need to go to every method
> and add it by hand: Well that is actually a problem, but i already have a solution for that, and is call
> ExpandableParameters, you can use any class with public fields an default public constructor as a method parameter, if
> you mark the method parameter as [Expandable] it will use that class to add more parameters to the operation, and you
> will get an instance of the object with the fields properly filled. Now i know that public fields are not really the
> best way to do it, but it was the fastest way to probe the concept. I will like to know if there is any interest in
> having support for properties instead of fields.
>
> I think this last addition solved the biggest name problem with it, in that way you can have a centralized object where
> the parameters are, with the advantage that you can have different classes grouping parameters, not only one. And is
> still possible to get the command dispatching saving you having to write all that if chains, and using control
> booleans.
>
> Take a look on the OnExample method of the example code.
>
> regards,
>
> Oscar.
>
> PS: Next add is support for serialized objects as parameters.
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
>
--
Rafael "Monoman" Teixeira
---------------------------------------
As I'm currently working a lot with Java and even fixing Java VMs
(JamVM/Kaffe) and GNU Classpath code, I think I may partly borrow the
title (Javaman) from my friend Bruno Souza and become the
MonoNJavaMan. Yeah, I may currently be crazier than usual...
More information about the Mono-devel-list
mailing list