It wasn't perfect and it's successor Mono.Options is a very capable replacement even if it doesn't do all the tricks Mono.GetOptions did in its prime.
Mono.Options is friendly to C# 3.0 features like lambdas, which allows writing code as terse as Mono.GetOptions allowed without using reflection and being a somewhat large dependency, the two main gripes Miguel had with my little library.
The last of Miguel gripes was about versioning (keeping more than one version in the fold) as some of the needed fixes and planned evolutions for Mono.GetOptions would mean breaking changes, which are better handled by consumers of the library by having distinct major versions with its separate APIs and attached series of minor releases.
That gets even more complex as you consider that Mono.GetOptions evolution also was tied to Mono releases.
If memory doesn't fail me, it was Mono.GetOptions and also other libraries imported into the project like SharpZipLib (which is still a problem as Mono is carrying two versions of it, and in this general cleanup process it is going over now we are trying to get rid of at least one of them), that prompted Miguel to change policy and ask for most non core libraries to be developed and released independently from Mono, even if developed by Mono hackers or used in some Mono utility. Better a package dependency (a soft one if possible) than the maintenance burden of embedded libraries.
Well let me quit reminiscing. Farewell my kid...
But if you are a loyal user of Mono.GetOptions what should you do?
You can:
- Migrate to Mono.Options (or even use it's code directly as Miguel advocated some time ago because it is a lot slimmer than my library).
- You can keep a copy of a Mono.GetOptions binary around to distribute with your solution (not an option for open source projects that would like to be accepted into Debian/Ubuntu).
- Tell me you would like to see Commons.GetOptions, my own fork of it, get on the air and fly high. Version 1.0 of it has just the namespace change in it, so your migration effort would be minimal. See the Managed Commons group for more information.
2 comments:
I would love a Commons.GetOptions! The gripe about dependencies makes a lot of sense, but it isn't an issue for me. GetOptions is so nice and easy to use, and I don't use lambdas in my options.
Moving to Mono.Options seems like the right move for Mono, but I would love to being able to keep using GetOptions myself.
Don's use "abandon" :) I agree that some nice things must be released outside of Mono. At least, I am one of those who uses Mono.Options source code directly in my open source projects.
Post a Comment