std.jgrandson

Sönke Ludwig via Digitalmars-d digitalmars-d at puremagic.com
Sun Aug 3 12:36:43 PDT 2014


Am 03.08.2014 20:44, schrieb Dicebot:
> On Sunday, 3 August 2014 at 08:04:40 UTC, Johannes Pfau wrote:
>> API looks great but I'd like to see some simple serialize/deserialize
>> functions as in vibed:
>> http://vibed.org/api/vibe.data.json/deserializeJson
>> http://vibed.org/api/vibe.data.json/serializeToJson
>
> Before going this route one needs to have a good vision how it may
> interact with imaginary std.serialization to avoid later deprecation.
>
> At the same time I have recently started to think that dedicated
> serialization module that decouples aggregate iteration from data
> storage format is in most cases impractical for performance reasons -
> different serialization methods imply very different efficient iteration
> strategies. Probably it is better to define serialization compile-time
> traits instead and require each `std.data.*` provider to implement those
> on its own in the most effective fashion.

Do you have a specific case in mind where the data format doesn't fit 
the process used by vibe.data.serialization? The data format iteration 
part *is* abstracted away there in basically a kind of traits structure 
(the "Serializer"). When serializing, the data always gets written in 
the order defined by the input value, while during deserialization the 
serializer defines how aggregates are iterated. This seems to fit all of 
the data formats that I had in mind.


More information about the Digitalmars-d mailing list