|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2005-02-15 23:16:26
Joel de Guzman <joel_at_[hidden]> writes:
> 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 don't mind tweaking my code. It seems "more principled" to supply a
backward-compatible interface. But I don't think the burden of the
cons-based tuple changing namespaces would be too much. So for
example, you could move it to boost::tuples::old::tuple _and_ make it
fusion-compatible. People who can only wrap their heads around a
small tweak will just tweak the namespace they use to refer to that
component. Others can start using the Fusion idioms right off.
Or you could do one more release with the old tuples where they are,
_and_ make them fusion-compatible. If you do that, my sense is that
nobody will switch right away, and they'll be just as surprised if
this changed after 2 releases as they would be if it changed after
one.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk