streaming redux

[Andrei Alexandrescu]

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.


Andrei