std.jgrandson
Jacob Carlborg via Digitalmars-d
digitalmars-d at puremagic.com
Tue Aug 5 09:20:18 PDT 2014
On 2014-08-05 11:54, Sönke Ludwig wrote:
> 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.
I have a very flexible trait like system in place. This allows to
configure the serializer based on the given archiver and user
customizations. To avoid having the serializer do unnecessary work which
the archiver cannot handle.
> BTW, how is the progress for Orange w.r.t. to the conversion to a more
> template+allocation-less approach
Slowly. I think the range support in the serializer is basically
complete. But the deserializer isn't done yet. I would also like to
provide, at least, one additional archiver type besides XML. BTW std.xml
doesn't make it any easier to rangify the serializer.
I've been focusing on D/Objective-C lately, which I think is in a more
complete state than std.serialization. I would really like to get it
done and create a pull request so I can get back to std.serialization.
But I always get stuck after a merge with something breaking. With the
summer and vacations I haven't been able to work that much on D at all.
, is a new std proposal within the next
> DMD release cycle realistic?
Probably not.
> 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.
I'm quite satisfied with the feature support and flexibility of
Orange/std.serialization. With the new trait like system it will be even
more flexible.
--
/Jacob Carlborg
More information about the Digitalmars-d
mailing list