streaming redux

[Robert Jacques]

On Tue, 28 Dec 2010 23:34:42 -0700, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 12/28/10 11:54 AM, Sean Kelly wrote:
>> Andrei Alexandrescu Wrote:
>>
>>> On 12/28/10 5:09 AM, Vladimir Panteleev wrote:
>>>>> abstract interface Formatter;
>>>>
>>>> I'm really not sure about this interface. I can see at most three
>>>> implementations of it (native, high-endian and low-endian variants),
>>>> everything else being too obscure to count. I think it should be
>>>> implemented as static structs instead. Also, having an abstract method
>>>> for each native type is quite ugly for D standards, I'm sure there's a
>>>> better solution.
>>>
>>> Nonono. Perhaps I chose the wrong name, but Formatter is really  
>>> anything
>>> that takes typed data and encodes it in raw bytes suitable for
>>> transporting. That includes e.g. json, csv, and also a variety of  
>>> binary
>>> formats.
>>
>> This one is really difficult to get right. JSON, for example, has
> named members of its object type. How could the name of a field be
> communicated to the formatter? The best I was able to do with C++
> iostreams was to create an abstract formatter class that knew about the
> types I needed to format and have protocol-specific derived classes do
> the work. Here's some of the dispatching code:
>>
>>      printer* get_printer( std::ios_base&  str )
>>      {
>>          void*&  ptr = str.pword( printer::stream_index() );
>>
>>          if( ptr == NULL )
>>          {
>>              str.register_callback(&printer_callback,  
>> printer::stream_index() );
>>              ptr = new xml_printer();
>>          }
>>          return static_cast<printer*>( ptr );
>>      }
>>
>>      std::ostream&  operator<<( std::ostream&  os, const  
>> message_header&  val )
>>      {
>>          printer* ptr = get_printer( os );
>>          return (*ptr)( os, val );
>>      }
>>
>> Actually using this code to write data to a stream looks great:
>>
>>      ostr<<  header<<  someobj<<  anotherobj<<  end_msg;
>>
>> but I'm not happy about how much specialized underlying code needs to  
>> exist.
>>
>> I guess what I'm saying is that a generic formatter may be great for
>> simple formats like zip streams, CSV files, etc, but not so much for
>> more structured output.  That may be a sufficient goal for
>> std.stream2, but if so I'd remove JSON from your list of possible
>> output formats :-)
>
> I agree with the spirit. In brief, I think it's fine to have a Json  
> formatter as long as data is provided to it as Json-friendly types  
> (ints, strings, arrays, associative arrays). In other words, I need to  
> simplify the interface to not attempt to format class and struct types -  
> only built-in types.

By the way, JSON doesn't support associative arrays in general. It only  
supports AA in the sense that JSON objects are an array of string:value  
pairs.