On 11/18/13, Atila Neves <[email protected]> wrote: >> I would suspect that the biggest reason is the limitations that >> that >> imposes on the underlying serialization implementation, as it >> would >> require that the underlying format support a minimum set of >> types. > > I'm not sure that's actually true. I've been working on my own > serialisation library in D that I plan to unleash on the announce > forum soon and it does it in a manner described by the original > poster. Even with custom serialisations, client code need only > define one function for both directions. > > The only reason I haven't announced it yet is because I wanted to > be pure it's polished enough, but maybe I shouldn't wait. > > Atila >
I am curious as to how exactly that would work, does it determine the output format at compile-time or runtime? Does it specify the way it's serialized, or it's serialized representation? I'd also be curious about the performance impact it brings, if any. Depending on it's exact function it's perfectly possible that it could actually be faster than my toString/parse combo because mine requires the string be allocated from toString, due to the lack of knowledge of the underlying format.
