[Mono-dev] Mono.GetOptions Option Bundles

[Rafael Teixeira]

Currently we are API and ABI frozen. You may change local copy and
submit a patch to be considered in some future version.

Personally I would like not to make things non-declarative,
specífically for those two  debugging itens we can have some global
disabler for such features, so that a release build of some app,
doesn't sport them.

Sorry I'm in a hurry just now,

Thanks,

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