Re: [boost] [review] Fusion review begins

From: Joel de Guzman (joel_at_[hidden])
Date: 2006-05-09 18:37:02

Powell, Gary wrote:

>> One note about fusion::tuple I/O manipulators:
>>
>> "The library defines three manipulators for changing the 
>> default behavior:
>> Manipulators
>> tuple_open(arg)
>> Defines the character that is output before the first element.
>> tuple_close(arg)
>> Defines the character that is output after the last element.
>> tuple_delimiter(arg)
>> Defines the delimiter character between elements."
>>
> Oleg> "Example:
> Oleg> std::cout << tuple_open('[') << tuple_close(']') << tuple_delimiter(",
> Oleg> ") << a;"
> Oleg> I see a usability issue here. I believe that if one needs to 
> Oleg> specify tuple_open then he would need to specify tuple_close too.
> Oleg> I propose to change tuple manipulators to be:
> Oleg> 1) tuple_bounds("(", ")") // if need to specify one bound, I 
> Oleg> need to specify both.
> Oleg> 2) tuple_delimiter(",") // I'm happy with bounds, but 
> Oleg> delimiter should be specified.
> Oleg> 3) tuple_punc("(", ",", ")") // I should specify all punctuation.
> 
> Hmmm. You may be right here, as there could be confusion from the following:
> 
> cout << tuple_open('[') << tuple_delimiter(';') << tuple(1,2) << tuple_close(']');
> 
> where it would output
> [1;2)
> instead of
> [1;2]
> 
> Oleg> furthermore, I believe that these manipulators are more 
> Oleg> general. They could be used with any sequence, not only with tuples.
> Oleg> May be it should be factored out to separate library and 
> Oleg> named appropriately?
> Oleg> 1) seq_bounds("(", ")") // if need to specify one bound, I 
> Oleg> need to specify both.
> Oleg> 2) seq_delimiter(",") // I'm happy with bounds, but delimiter 
> Oleg> should be specified.
> Oleg> 3) seq_punc("(", ",", ")") // I should specify all punctuation.
> Oleg> seq stands for sequence.
> 
> The issue is that if you use a facet to do punct, it's tied to the
> type of container.
> 
> I apologize for not looking at what the current code does, but the
> stuff I wrote orginally was tied directly to the tuples.

The code there was originally written by Jaakko Järvi and Jeremiah
Willcock specifically for a tuple TR1 implementation based on a
flat (vector style) tuple code that I wrote around 2002. I've since
changed it to something generic that can accommodate any sequence
type. Yes, I believe that can be factored out into a library (utility)
of its own.

I agree with the suggestions too.

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