Re: [boost] Breaking existing libraries

Subject: Re: [boost] Breaking existing libraries
From: Dave Handley (dave_at_[hidden])
Date: 2008-11-24 08:15:53

----- Original Message ----- 
From: "vicente.botet" <vicente.botet_at_[hidden]>
Newsgroups: gmane.comp.lib.boost.devel
To: <boost_at_[hidden]>
Sent: Monday, November 24, 2008 2:06 AM
Subject: Re: Breaking existing libraries

>
> ----- Original Message ----- 
> From: "Dave Handley" <dave_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Monday, November 24, 2008 2:08 AM
> Subject: Re: [boost] Breaking existing libraries
>
>
>>
>> Vicente Botet wrote:
>>
>>> ----- Original Message ----- 
>>> From: "Thorsten Ottosen" <thorsten.ottosen_at_[hidden]>
>>> To: <boost_at_[hidden]>
>>> 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