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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] _______________________________________________ Mono-devel-list mailing list Mono-devel-list@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...
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
