----- Original Message ----- From: "vicente.botet" <vicente.botet@wanadoo.fr> Newsgroups: gmane.comp.lib.boost.devel To: <boost@lists.boost.org> Sent: Monday, November 24, 2008 2:06 AM Subject: Re: Breaking existing libraries
----- Original Message ----- From: "Dave Handley" <dave@dah.me.uk> To: <boost@lists.boost.org> Sent: Monday, November 24, 2008 2:08 AM Subject: Re: [boost] Breaking existing libraries
Vicente Botet wrote:
----- Original Message ----- From: "Thorsten Ottosen" <thorsten.ottosen@dezide.com> To: <boost@lists.boost.org> Sent: Sunday, November 23, 2008 11:50 PM Subject: Re: [boost] Breaking existing libraries
Dave Handley skrev:
I have looked it up, and its not documented. Period.
Anyway, I'm sorry you feel the way you do. I don't intentionally try to break people's code, and I have put an enourmous effort into the code I've submitted to boost.
FWIW, boost.range is not changing anymore.
Unfortunately, you've already broken my confidence - unless of course, we can come up with a decent compromise on this which seems further away by the hour.
If the compromise does not include going back to the old behavior for boost::iterator_range, then I'm open to suggestions (If we did that, how would we explain that situation to all those that want the current behavior?).
Some one has already proposed boost::old_iterator_range and if I remember well you have proposed boost::deprecated::iterator_range.
"I guess The old behavior could be supplied in <boost/range/deprecated/iterator_range.hpp> in namespace boost::deprecated. Again, it is a matter of time."
Is this a good compromise for all?
Not really - as a library user you can't rely on deprecated functionality. If my code was broken by this change, and the change was reverted in a deprecated version, I would probably just drop the library out of the (valid?) fear that the deprecated interface would be dropped at some point.
Can I conclude that you don't think that libraries evolve and for that some functionalities must be deprecated. Note that the name of the class be boost::old_iterator_range or boost::deprecated::iterator_range doesn't matter.
My argument all along is that I think both functionalities are equally valid. And I don't think there is a sensible migration path from one to the other. As such, both classes should be in boost. However, during the discussion on this I ran into some rather intractable brick walls which mean I've just given up on the library.
The proposal that has been made multiple times in the other thread is that both types of functionality are valid, and that there should just be 2 classes. One could easily be made to inherit off the other, both would be useful for different use cases. As far as I can tell, no-one has made a solid critique against that proposal, but on the other hand, there still doesn't appear to be a consensus.
I haven't the backgraund on this domain to prononce myself.
I really wouldn't be surprised if the sum total of all this discussion in about 4 different threads on 2 different mailing lists is that absolutely nothing happens. I would like that not to be the case, but by past experience, I'm not holding my breath.
This will depend on all the participants. If they are unable to find a compromise there is no reason to change.
Please could you reconsider your possition? A deprecated interface will give you the opportunity to have again the fonctionality, and let you time to switch to the new one. How many time would be enough for you?
This would be useless - there isn't a sensible migration path, so without the original functionality available and supported in some form, we might as well drop the library and use something that will be stable in the future. Thanks for your help on the Vicente, you are one of the few pragmatic types on the list - and I wish you the best with your effort for documenting breaking changes. It's just a shame that discussions on this list get bogged down in irrelevancies - that stopped me from posting to this list 3 or 4 years ago, and my experience this time hasn't helped persuade me to get involved again. Dave