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? On Mon, Feb 17, 2014 at 12:18 AM, Orvid King <[email protected]> wrote: > 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. >
