+972 52-548-6969
NH Prof is version tolerant
From the get go, I decided that I wanted NH Prof to work without having an explicit dependency on a particular version of NHibernate. I had trouble with that when I built the NHibernate Query Analyzer, and I had enough of that.
This is especially true since I am one of the target audience of NH Prof, and I would hate having to manage NH Prof <---> NHibernate version mapping. So I set out to make NH Prof version tolerant. My explicit goal was to be able to work with NHibernate 2.0 and up.
Along the way, I did something that is pretty surprising. NH Prof also work with NHibernate 1.2, which I never even tried to test with. When I say works, I mean that most of the things work as usual, but some of the fine points are missing (for example, I know that showing entity identifiers are not working in 1.2).
That is quite encouraging, and probably means that I can support 1.2 fully without too much hassle. But,
It also means that going forward, I am going to have a much easier time with adding new features to NH Prof as they appear in NHibernate.
Overall, I am pretty happy about this.
Comments
What sort of tricks are you using if I may ask? I have been apart of the BooLangStudio group and one of the things we were talking about was to not be dependent upon a specific version of Boo.Lang (so you could build boo from source without having to update the plugin) but we're unsure how to have strong references to assemblies (or assemblies with breaking changes) without using pure reflection.
I can see the passion you have for this tool in the your writing about it. It's pretty cool, and it makes me want to find a way to use it. I'll be using NH for the my next .Net project where I can make that decision.
A lot of the time this is relying on things that rarely change. I am doing a lot with the log output, for example.
Another thing that we do is dynamic invocation. It sucks, I admit, but it allow us to avoid using a hard dependency.
Nothing can protect me from all changes, but for most? It just works.
I think this can be considered a bad or a good idea depending on the versions you support.
If you support major versions, like 1.2/2.0, it's good. If you want to support 2.0.0 and 2.0.1 at the same time, it's bad because:
You end up using dynamic invocation in way too many places. This is bad for performance and for the readability of your code.
You don't encourage people updating their software. If it's a major version, it's understandable because you may have not prepared your software yet, but minor versions almost always mean bugfixes which will not likely introduce regressions.
Andrés
I am not in the business of making people to update their software. I am in the business of supporting as wide a variety as I can possibly can.
As for dynamic invocation , I am not woried about that.
Well, it's more or less like the eternal discussion between webdevelopers and users: should I support IE5 for my webpage? It's a trade-off, the more versions you support, the more spaghetti/unmaintainable/inefficient code you get, and in this case it's called dynamic invocation. There's a point in which, encouraging people to update software is a benefit to all, even if that people are your customers (of course, this on the opensource world makes much more sense as well ;)
Comment preview