[Mono-list] C# command line parsing library

Tue Jan 9 10:52:41 EST 2007

Hi,

Firstly I´d like to not that I have not used mono.GetOptions myself so I
will be mostly talking out of my own ass.

I have been searching for a convenient way to handle parameters in .net
world but came up short.  I really do like the attribute based approach used
in GetOptions an I am very likely to use it next time I need at tool like
that.

Now what I really wanted to talk about is the standardization of commandline
parameters and how reflection can make life more interesting.

The other day I was moaning about the problem *nix command line tools (which
is also part of it´s gratest strenghts) that there is little stadardization
going on and every tool seems to have it´s own querks and peculiarities.
The man pages tend to have little meaning untill you reach level 15 in *nix
sourcery.

So what I'm thinking of is a tool such as mono.GetOption x.0 where you
declare options with attributes and give descriptions switch names and
shortcuts and optional validators (email, ip-address, number, int, double
etc.) and preferable have help generated automatically through
(possibley/hopefully with embedded l18n internationalization).  This in turn
gives rise to interesting options outside the program. For instance in
command shell autocomplete for options using reflection and even with
validation (which would be sweet). You could probably have generic GUI's
generated with all the options generated for you with dropdown lists for
enums for validated boxes for ip's when you launch a mono app in the window
manager of your choise by double clicking.

This may be a little far fetched but I thought I'd share this with you smart
people since there is a releant discusion going on.

For this to work to any extent you would have to have a "simple",  stable
and popular option/param library :)

my 2 kronas

regards,
Freyr

On 1/9/07, Rafael Teixeira <rafael.teixeirabr at terra.com.br> wrote:
>
> Thanks Miguel for the clarifications.
>
> I think I'll start Mono.GetOptions 2.0 (or more probably a
> Commons.GetOptions) outside of Mono, and just keep Mono.GetOptions 1.0
> stable (only security fixes) inside Mono svn.
>
> I'll post details as I progress with it. But some of the ideas I already
> have are:
>
> -- to make it I18n-friendly (either gettext and resources, by
> defining/using localization providers and matching tools)
> -- drop the multiple constructor overloads for the attributes, in favor
> of the supported syntax for field initialization by name
> -- refactoring into a layered design, that should allow for imperative
> definition of option sets, besides the declarative form currently
> supported
> -- subcommands support
> -- easier runtime addition of options
> -- a tool to compile a DSL (Domain Specific Language) to a binary
> options library and/or generate (cia codedom) a partial classes sources
> in any language taht have correct codedom support installed.
> -- a GTK# GUI tool (also wrapped as a MD plugin) to write the above DSL
> (some call it a graphical DSL)
> -- A WinForms component/editor to define/generate/use the DSL
> -- Full Monodoc/VSNET Documentation
> -- Sample code also in Boo, VB.NET and Java(IKVM)
>
> Nevertheless suggestions are welcome.
>
> Fun
>
> On Mon, 2007-01-08 at 13:04 -0500, Miguel de Icaza wrote:
> > Hello,
> >
> > > I don't think it has too much limitations, but I would like some bug
> > > reports for any limitations or lacking features that all of you, users
> > > and potential users of it, could file to assess what I should improve.
> > > Direct code/documentation contributions are also welcome.
> >
> > As I explained to a volunteer that contacted me over email, the problem
> > is not only related to the existing limitations of Mono.GetOptions, but
> > it is further constrained by the fact that further API changes are not
> > likely going to go in (because it would break older applications).
> >
> > API additions, updates and changes are better suited to an upgraded API,
> > and if I were to make the decision today about shipping a GetOptions
> > library, I would not put that in the core of Mono.
> >
> > This goes to a more general issue: I think we were too lax accepting new
> > APIs that were evolving into the Mono core, which is why these days the
> > answer to "Could you bundle MyFavoriteLibraryThatIJustDeveloped in Mono"
> > is "no".
> >
> > Because we have to maintain backwards compatibility, this means: if you
> > break the API, we have to ship *two* versions of the library (see
> > ICSharpCode.ZipLib, we ship *two* because of this) and we have to carry
> > the burden for these API changes.
> >
> > We have documented the process to have unstable APIs in the "Application
> > Deployment Guidelines" on the Wiki, and many of the APIs that today we
> > ship with Mono should have gone first through that process, and only
> > when stabilized bundled with Mono.
> >
> > Bundling stuff with Mono imposes a lot of constraints on developers: API
> > stability, tests, release schedule.   But it also imposes a lot of extra
> > work on us: if a critical bug, security problem or something else is
> > found on those libraries, we must stop whatever it is that we are doing
> > and start the release process, the advisory process and get things
> > moving to address the issues.
> >
> > This is why we moved Olive into its own release schedule: because the
> > core of Mono is stable, has calcified and Olive is better served with a
> > process that has its own release schedule, that can release updates as
> > frequently as it needs (when its ready to ship) and can fix bugs on its
> > own schedule.
> >
> > And this is also why we are doing it for Basic, mbas is dead, its gone
> > from the tree, and so are the class libraries for Visual Basic: the vbnc
> > and vbruntime components are younger, and need to be on their own
> > release schedule, they are moving at a different speed, and bundling
> > with Mono just imposes a structure that is not apt for technologies
> > under heavy development.
> >
> > We would have done the *same* for Windows.Forms, were it not for the
> > internal dependencies in our own assemblies (ie, have Windows.Forms
> > releases that are completely independent of Mono).
> >
> > We should have known better;   There is the rule from Brad Cox: an API
> > is not mature until you have three very different applications consuming
> > it and not until you have tests cases, understanding of limitations and
> > expanded features that you should declare it as stable.
> >
> > Miguel
> > _______________________________________________
> > Mono-list maillist  -  Mono-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-list
> >
> > E-mail classificado pelo Identificador de Spam Inteligente Terra.
> > Para alterar a categoria classificada, visite
> >
> http://mail.terra.com.br/protected_email/imail/imail.cgi?+_u=rafael.teixeirabr&_l=1,1168279480.288645.615.arrino.hst.terra.com.br,6351,Des15,Des15
> >
> > Esta mensagem foi verificada pelo E-mail Protegido Terra.
> > Scan engine: McAfee VirusScan / Atualizado em 05/01/2007 / Verso: 5.1.00
> /4933
> > Proteja o seu e-mail Terra: http://mail.terra.com.br/
> >
>
> _______________________________________________
> Mono-list maillist  -  Mono-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-list/attachments/20070109/c0e8b814/attachment-0001.html 