<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 8 aug 2010, at 15:30, Michel Fortin wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Le 2010-08-08 à 6:46, Jacob a écrit :<br><br><blockquote type="cite">On 8 aug 2010, at 07:47, Andrei Alexandrescu wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">I think that would be great. Knowing nothing about Orange, I visited the website and read the feature lists and the tutorial (the reference seems to be missing for now). The latter contains:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">auto a2 = serializer.deserialize!(A)(data);<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">which seems to require compile-time knowledge of the deserialized type. I'd expect the library to support something like<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Object a2 = serializer.deserialize!Object(data);<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">This is currently not possible in the library. I'm not sure if that would be possible, how would you deserialize a struct for example? There is no factory function for structs like there is for classes.<br></blockquote><br>But there's no concept of derived struct. For a struct you always know the type at compile-time. The only way to hide a struct would be behind a void* or void[], but trying to serialize/unserialize that type automatically (without the user writing the serialization code itself) is pointless.<br></div></blockquote><div><br></div><div>Yes, exactly, that is how the library currently works. But I can see how starting out by deserializing with the type Object could work. This is a description of how the serializer "thinks" when it deserializes a value:</div><div><br></div><div>auto a2 = serializer.deserialize!(Foo)(data);</div><div><br></div><div>"Ok, I'm deserializing a Foo"</div><div><br></div><div>1. Start by creating a new instance of Foo</div><div>2. Loop through all the instance variables</div><div><br></div><div>"Oh, I found a struct of the type Bar"</div><div><br></div><div>1. Create a new Bar</div><div>2. Loop through all the instance variables</div><div>3. Deserialize the values for each variable</div><div>4. Set the values for all the instance variables</div><div><br></div><div>3. Set the value for the instance variable of type Bar</div><div><br></div><div>continue deserializing...</div><div><br></div><div>Using the approach above I have all (or as much as possible) compile time information available, like the types of all the instance variables, the serializer is in control. Using Andrei's approach it seems more like this:</div><div><br></div><div>"Start looking in the archive after types"</div><div>"Ok, the archive wants me to deserialize an instance of Foo"</div><div><br></div><div>1. Start by creating a new instance of Foo using reflection:</div><div><br></div><div>Object foo = Object.factory("Foo");</div><div><br></div><div>2. In the archive, loop through all the instance variables</div><div>3. See if there is a corresponding field in the deserialized object by loop through all the instance variables using foo.getMembers</div><div>4. "Ok the archive wants me to deserialize a struct of the type Bar, hm how do I do that? I only have Bar as a string"</div><div><br></div><div>Using this approach all compile time information is lost, the archive is in control. Probably not the best explanation.</div><br><blockquote type="cite"><div>Or you could hide it behind a variant, in which case the variant's serialization should remember the type name so it can find a proper deserializer on the other side. How exactly it does that? Either with better runtime-reflection, or with pre-registered handlers on the unserializer's side (not very convenient).<br><br><br><blockquote type="cite">Since all the static types of the objects would be Object how would I set the values when deserializing? Or would Variant be useful here? I have not used Variant.<br></blockquote><br>At this point I've been unable to serialize/unserialize a variant.<br><br>Another interesting point: it's probably necessary to be tolerant of type differences. For instance, if I serialize a size_t on a machine and unserialize it elsewhere, it might not be the same underlying integral type.<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><div><br></div>That deserves to think about.<br><div><br></div><blockquote type="cite"><div>-- <br>Michel Fortin<br><a href="mailto:michel.fortin@michelf.com">michel.fortin@michelf.com</a><br>http://michelf.com/<br><br><br><br>_______________________________________________<br>phobos mailing list<br>phobos@puremagic.com<br>http://lists.puremagic.com/mailman/listinfo/phobos<br></div></blockquote></div><br></body></html>