[boost] Re: Fusion plan [was Re: tuple patch (constructing from apair)]

From: Joel de Guzman (joel_at_[hidden])
Date: 2005-02-16 06:46:43

Jaakko Järvi wrote:
> 
> On Feb 15, 2005, at 7:31 PM, Joel de Guzman wrote:
> 
>> Jonathan Turkanis wrote:
>>
>>> Joel de Guzman wrote:
>>>
>>>> Jonathan Turkanis wrote:
>>>>
>>>>> Joel de Guzman wrote:
>>>>>
>>>>>> 5) Provide a tuple TR1 interface on top of fusion.
>>>>>> 6) Provide a backward compatible interface (for old tuples) on
>>>>>>   top of fusion.
>>>>>
>>>>> Also, I think having both 5) and 6) will be confusing. I'd prefer to
>>>>> get rid of 6). This will obviously break some code, but it will be
>>>>> much easier to adapt old code to the new interface than it was,
>>>>> e.g., to adapt code to use the new iterator adaptors.
>>>>
>>>>
>>>> 5 and 6 will have to either-or through a PP define. Yes, it
>>>> can't be both at the same time. We can deprecate 6 and
>>>> phase it out in the future. We can't simply kill it now.
>>>> TR1 deos not provide a way to extend a tuple, for example.
>>>
>>> Okay, I thought people who used cons lists were relying on an 
>>> implementation
>>> detail, but I see that it is  documented under "advanced features."
>>> Still, I'm not sure why you can't eliminate 6) at the same time you 
>>> introduce
>>> fusion. People who need extensible tuples can use fusion sequences.
>>
>>
>> That will lessen my work a lot. But don't you think that's too
>> abrupt? Perhaps those who use old tuple's advanced features are
>> advanced users anyway who won't mind tweaking their code? Toughts?
>> Jaakko? Anyone?
>>
> I think it would be too abrupt (to just not provide the old tuple 
> features). Even thought directly relying on cons lists are documented
>  as advanced features, they are documented. But I think it would be 
> fine to just keep the old tuples around for a few releases, and not 
> bother replicating the old interface on top of fusion. That would 
> seem like a wasted effort.
> 
> We could just have a #define like BOOST_USE_OLD_DEPRECATED_TUPLES 
> that would include the old implementation.

It won't really be a wasted effort. 1) I can take advantage of more
user's code base to test the implementation for things that are
not covered by the regression tests. 2) Users can already use
features outside the classic tuples API such as the algorithms
like for_each, find_if, etc.

OTOH, I have only limited time, so I am now inclined to simply
keep the old tuples around. Depends, I guess on how much effort
the compatibility layer will take. If it's just a day or two
of coding, then I think it's time well spent.

> If a user downloads a new release of Boost, and realizes that his
> code that relies on old tuple features does not work, there would be
> a quick fix with the #define, but it would clearly indicate that it's
> time to rework parts of the code. >

Right. I loud nagging warning might be just what we need.
Something like: "warning: 3 months to go before this becomes history",
then... "warning: 2 months to go before this becomes history",
then... "warning: 1 month to go before this becomes history",
then... "You missed the train. I warned you, didn't I?",

:-)

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net