Re: [boost] Breaking existing libraries

Subject: Re: [boost] Breaking existing libraries
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-11-24 02:06:09

----- 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.

> 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?

Best regards,
Vicente