Am 04.08.2014 20:38, schrieb Jacob Carlborg:
On 2014-08-04 16:55, Dicebot wrote:
That is exactly the problem - if `structToJson` won't be provided,
complaints are inevitable, it is too basic feature to wait for
std.serialization :(
Hmm, yeah, that's a problem.
On the other hand, a simplistic solution will inevitably result in
people needing more. And when at some point a serialization module is in
Phobos, there will be duplicate functionality in the library.
I am pretty sure that this is not the only optimized serialization
approach out there that does not fit in a content-insensitive
primitive-based traversal scheme. And we won't Phobos stuff to be
blazingly fast which can lead to situation where new data module will
circumvent the std.serialization API to get more performance.
I don't like the idea of having to reimplement serialization for each
data type that can be generalized.
I think we could also simply keep the generic default recursive descent
behavior, but allow serializers to customize the process using some kind
of trait. This could even be added later in a backwards compatible
fashion if necessary.
BTW, how is the progress for Orange w.r.t. to the conversion to a more
template+allocation-less approach, is a new std proposal within the next
DMD release cycle realistic?
I quite like most of how vibe.data.serialization turned out, but it
can't do any alias detection/deduplication (and I have no concrete plans
to add support for that), which is why I currently wouldn't consider it
as a potential Phobos candidate.
