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