[Mono-list] C# command line parsing library

[Rafael Teixeira]

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/
>