From: Jaakko Järvi (jarvi_at_[hidden])
Date: 2005-02-16 00:26:35
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.
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.
Best, Jaakko