[Mono-dev] Mono.GetOptions Option Bundles
Almann T. Goo
almann.goo at gmail.com
Fri May 5 10:39:02 EDT 2006
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060505/87b19f0d/attachment.html
More information about the Mono-devel-list
mailing list