On Sunday, 16 February 2014 at 22:33:07 UTC, Orvid King wrote:

> The problem with the way your doing it though is that it requires that the library doing the deserialization is fully aware of the semantics used in the serialization implementation, rather than just the syntax and semantics of the selected serialization format.

I don't see why that is required.

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

On Monday, 17 February 2014 at 06:14:51 UTC, Rory McGuire wrote:
> Do you have a JSON driver for Orange yet? Would be interesting to benchmark
> Orange against a purpose designed JSON serialization library.
> If your design is mostly compile time the experiment would be very
> interesting (I think).

Unfortunately no. I have worked on adapting a range interface and also making the current requirements for implementing an archiver (format) more flexible.

--
/Jacob Carlborg

On Monday, 17 February 2014 at 06:09:35 UTC, Rory McGuire wrote:

> A base class reference is: from your example an A which actually contains a
> C or B.
>
> Honestly I haven't tried this I would have assumed that D still gives you
> the real type when using reflection but have you tried it?

Unfortunately the only why to get a value of field by reflection requires the static type to be known. When serializing through a base class reference the static type is lost. Therefore it's required to register the subclass, one way or another.

--
/Jacob Carlborg

Interesting, do you have to run though all registered classes that are sub-classes of the base class and cast them checking for null?


On Mon, Feb 17, 2014 at 9:24 AM, Jacob Carlborg <doob@me.com> wrote:

> On Monday, 17 February 2014 at 06:09:35 UTC, Rory McGuire wrote:
>
>  A base class reference is: from your example an A which actually contains
>> a
>> C or B.
>>
>> Honestly I haven't tried this I would have assumed that D still gives you the real type when using reflection but have you tried it?
>>
>
> Unfortunately the only why to get a value of field by reflection requires the static type to be known. When serializing through a base class reference the static type is lost. Therefore it's required to register the subclass, one way or another.
>
> --
> /Jacob Carlborg
>

On 2014-02-17 13:20, Rory McGuire wrote:
> Interesting, do you have to run though all registered classes that are
> sub-classes of the base class and cast them checking for null?

No, that's not required. When a subclass is registered I'm storing a templated delegate which performs the downcast. Have a look at these two methods:

https://github.com/jacob-carlborg/orange/blob/master/orange/serialization/Serializer.d#L241-L262

-- 
/Jacob Carlborg

On Mon, Feb 17, 2014 at 10:10 PM, Jacob Carlborg <doob@me.com> wrote:
>
> No, that's not required. When a subclass is registered I'm storing a templated delegate which performs the downcast. Have a look at these two methods:
>
> https://github.com/jacob-carlborg/orange/blob/master/orange/serialization/ Serializer.d#L241-L262
>
> --
> /Jacob Carlborg
>
interesting thanks.

On Sunday, 16 February 2014 at 20:57:28 UTC, Andrej Mitrovic wrote:
> On 2/16/14, "Nordlöw" <per.nordlow@gmail.com> wrote:
>> I'm however not sure how serialization of base and superclasses
>> should be implemented in the most convenient way. Maybe somehow
>> has a good suggestion for this.
>
> One way to do it:
> https://github.com/msgpack/msgpack-d#use-own-deserialization-routine-for-class-and-struct

That suffers from needing two functions to serialise/deserialise when only one should be needed.

Atila

On Monday, 17 February 2014 at 07:24:11 UTC, Jacob Carlborg wrote:
> On Monday, 17 February 2014 at 06:09:35 UTC, Rory McGuire wrote:
>
>> A base class reference is: from your example an A which actually contains a
>> C or B.
>>
>> Honestly I haven't tried this I would have assumed that D still gives you
>> the real type when using reflection but have you tried it?
>
> Unfortunately the only why to get a value of field by reflection requires the static type to be known. When serializing through a base class reference the static type is lost. Therefore it's required to register the subclass, one way or another.
>
> --
> /Jacob Carlborg

Yeah, I still have to implement that for cerealed.

Atila