From: Joel de Guzman (joel_at_[hidden])
Date: 2005-02-15 04:33:42
Jonathan Turkanis wrote:
> Joel de Guzman wrote:
>>Ok, replying to myself, here's what I am planning:
>>1) I intend to refactor fusion to allow different forms of
>> containers with varying characteristics. I plan to have:
>> a) vector
>> b) list
>> c) set
>> d) map
>>2) The unifying force is the (as usual): iterator
>>3) There will be intrinsic functions that work on specific
>> containers (e.g. cons for lists; thus having full backward
>> compatibility with old tuples).
>>4) As I intend to follow the MPL mold, I will follow MPL
>> naming convention (e.g. "at" instead of "get", vector
>> instead of tuple).
>>5) Provide a tuple TR1 interface on top of fusion.
>>6) Provide a backward compatible interface (for old tuples) on
>> top of fusion.
>>I'd like to hear your thoughts.
> What namespaces would the various components go in? I understand the plan had
> been to move the contents of boost::fusion into boost::tuples, but if the
> primary sequence type is no longer going to be called tuple, I'd rather have
> fusion stay in boost::fusion and just put the TR1 interface in boost::tuples.
I agree with you.
> 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.
-- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk