Request for review - std.serialization (orange)

Jacob Carlborg doob at me.com
Mon Apr 1 01:49:37 PDT 2013


On 2013-04-01 07:15, Kagamin wrote:
> It's a pull parser? Hmm... how reordered fields are supposed to be
> handled? When the archiver is requested for a field, it will probably
> need to look ahead for the field in the entire message. Also arrays can
> be discontinuous both in xml and in pb. Also if the archiver is
> requested for a missing field, it may be a bad idea to return
> typeof(return).init as it will overwrite the default value for the field
> in the structure. Though, this may be a minor issue: field usually is
> missing because it's obsolete, but the serializer will spend time
> requesting missing fields.

Optional fields are possible to implement by writing a custom serializer 
for a given type.

The look ahead is not needed for the entire message. Only for the length 
of a class/strcut. But since fields of class can consist of other class 
it might not make a difference.

> As a schema-informed serialization, PB works better with specialized
> code, so it's better to provide a means for specialized serialization,
> where components will be tightly coupled, and the archiver will have
> full access to the serialized type and will be able to infer schema.
> Isn't serialization simpler when you have access to the type?

Yes, it would probably be simpler if the archive had access to the type. 
The idea behind Orange is that Serializer tries to do as much as 
possible of the implementation and leaves the data dependent parts to 
the archive. Also, the archive only needs to know how to serialize 
primitive types.

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list