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

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.

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