[Mono-dev] Mono.GetOptions Option Bundles

[Rafael Teixeira]

Sorry forgot to think :(

Nothing mandates that you use the standard bundle as the basis, you
can create your own with just the needed options. The down side is
that some functionality would have to be duplicated in that case.

:)

On 5/5/06, Almann T. Goo <almann.goo at gmail.com> wrote:
> I've been using Mono.GetOptions for a compiler project of mine and it is a
> great library for option parsing.  However, there is an issue that I've run
> into that is slightly troublesome.  I wanted to run this issue by the
> community in case I missed a workaround or a solution--documentation is a
> bit sparse and the source doesn't seem to indicate a way to work around the
> described issue.
>
> Currently the option bundle is defined as a sub-class of the Options class.
> For bundles that don't want the standard options, you can attribute an
> overridden method that is attributed as an option with the
> KillOptionAttribute attribute.  This works well for virtual methods that are
> decorated as part of the option bundle, but for non-virtual members ( i.e.
> fields and properties) this poses a problem since you cannot override such
> members.
>
> This affects the VerboseParsingOfOptions and DebuggingOfOptions members in
> particular since these are non-virtual properties and you will always have
> these options regardless of what you may desire.
>
> If there is no known work around for this, I would suggest (and may even
> develop the fix for if I have time) that an OptionBundle interface be
> defined.  This interface would be member-less and the existing Options class
> could implement it and store it as a property (defaulting to a self
> reference).  An implementation could then explicitly define its own
> OptionBundle irrespective of the standard Options class which may invoke the
> standard options defined.  The point would be that the application could
> have better control over what options are in the bundle.  The meta-data
> approach is a nice one, but the inheritance hierarchy and non-virtual
> members could get in the way; this would solve that.
>
> The OptionList class (and possibly the OptionDetails class, but I am pretty
> sure it is not dependant on introspecting the option bundle) would need to
> be changed to work with OptionBundle.  Furthermore, backwards compatibility
> would be maintained with how Mono.GetOptions is used today since the default
> value of the property in the Options class would be itself.  To use this new
> feature you would probably override the InitializeOtherDefaults method to
> set the property to the desired bundle implementation.
>
> Best Regards,
> Almann
>
> --
> Almann T. Goo
> almann.goo at gmail.com
> _______________________________________________
> 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...