std.serialization

[Jacob Carlborg]

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 
> that.

I see.

> 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.

Ok.


> 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.

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 
current API.

--
/Jacob Carlborg