std.serialization
Orvid King
blah38621 at gmail.com
Sun Feb 16 14:18:53 PST 2014
> Why not? Think of languages like C and C++, they only support pointers.
> Pointers to basic types are not so interesting but pointers to structs
> are.
Because, by serializing a pointer, you are implying that mechanism that
will be deserializing the value both exists on the same machine, and lies
within the same address space, otherwise it will be referencing incorrect
data.
> If the same reference value is encountered multiple times, is it
> serialized once or multiple times?
It is currently serialized multiple times. Serializing once would require
a mechanism to exist on both the serializer and deserializer that
understands and can interpret those references. As there is not a standard
mechanism in JSON to support this, I haven't actually gotten around to
implementing that.
> What? I'm referring to methods being called before and after
> serialization of a given value.
Woops, that means I simply mis-understood your question. The answer to
your actual question is somewhat, there is a single code path for dynamic
types, I've only implemented support in a modified version of
Destructionator's JSVar library, but it should be possible to add support
to Variant without any real issue, that does support javascript's 2
parameter json serialization, there are not however callbacks for the
start and end of serialization.
> I prefer opt-out rather than opt-in.
Well, if I ever get around to cleaning up the codebase enough to submit it
for inclusion in Phobos, there can be a nice long discussion about the
pro's and con's of each, because it's a very simple check to remove.
> Can it serialize through base class references?
It currently retrieves all fields present in the class heirarchy, so if
you have classes A, B, and C defined as follows:
class A
{
@optional
int aA = 10;
}
class B : A
{
@serializeAs("Bob")
int bob;
}
class C : B
{
int cA;
@nonSerialized
int cB;
}
Then calling toJSON on an instance of class C, and have modified the value
of aA, it will produce a result containing fields defined as aA, Bob, and
cA.
Because cB is marked as @nonSerialized, it is ignored during serialization.
Next, bob is serialized as Bob because it is marked as @serializeAs which
is intended to account for the difference in naming conventions between
different languages, in this case the source of the serialized data may
very well be C#, where the convention is typically PascalCase. We however
are programming in D, where, if you're me at least, you use camelCase for
fields.
Lastly, if we hadn't modified the value of aA, and it was still 10, it
would not be included in serialization results, because it is marked as
@optional, and contains the same value it would were it default
constructed.
More information about the Digitalmars-d-announce
mailing list