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