On Sunday, 16 February 2014 at 22:41:59 UTC, Orvid King wrote:
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.
No. I'm serializing a pointer by dereferencing and serialize what
it points to as I normally would. Then it's indicated in the
serialized format it is a pointer. Then when deserializing I just
use "new" to get a pointer and just set the values.
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
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
serialization, there are not however callbacks for the start
and end of serialization.
It currently retrieves all fields present in the class
heirarchy, so if you have classes A, B, and C defined as
int aA = 10;
class B : A
class C : B
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
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.
I mean this case:
A c = new C;
toJSON(c); // the static type info of C is lost here
It seems you have limited yourself to what the JSON format
supports. I tried to be as flexible as possible. My upcoming
modifications to Orange, or rather std.serialization am working
on, will have some small differences to the current API of
Orange. Although I'm hoping it will be much more flexible then