[Mono-dev] Mono.GetOptions Option Bundles
monoman at gmail.com
Fri May 5 11:00:06 EDT 2006
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,
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
> 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 T. Goo
> almann.goo at gmail.com
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
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