<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 17 sep 2010, at 08:02, Andrei Alexandrescu wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>This exchange involves serialization design. It replies to Michel's email on Aug 8.<br><br>On 8/8/10 7:26 CDT, Michel Fortin wrote:<br><blockquote type="cite">Le 2010-08-08 à 1:47, Andrei Alexandrescu a écrit :<br></blockquote>[snip]<br><blockquote type="cite"><br></blockquote><blockquote type="cite">My own unreleased, unfinished and in-need-of-a-refactoring<br></blockquote><blockquote type="cite">serialization module does that... but unfortunately dynamically<br></blockquote><blockquote type="cite">recreating the right type cannot be so straightforward in the current<br></blockquote><blockquote type="cite">state of runtime reflection.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">This post turned out longer that I expected, please stay with me.<br></blockquote><br>OK. Apologies for taking so long.<br><br><blockquote type="cite">Runtime reflection currently gives you access *only* to the default<br></blockquote><blockquote type="cite">constructor, so this is what my module do internally when<br></blockquote><blockquote type="cite">unserializing a class:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">ClassInfo c = findClass(classNameFromSerializationStream); Object o =<br></blockquote><blockquote type="cite">c.create(); (cast(Unserializable)o).unserialize(serialiationStream);<br></blockquote><br>Yes, and that's entirely sensible. You create an empty object using standardized header information from the stream, and then you fill it with type-specific information by continuing down the stream. It's good practice.<br><br><blockquote type="cite">Since we can't access a constructor with a different signature, we<br></blockquote><blockquote type="cite">can't unserialize directly from the constructor.<br></blockquote><br>I think that would be ill-advised too. It's not constructor's job to deserialize.<br><br><blockquote type="cite">This is rather a<br></blockquote><blockquote type="cite">weak point as it forces all objects to have a default constructor.<br></blockquote><br>Only all objects that want to support serialization.<br></div></blockquote><div><br></div><div>We can just skip calling the constructor and let the user register a function/method that does any custom deserialization if needed. Then all objects can be deserialized. This is only needed if the user of the serializer wants perform any custom deserialization (run any custom code) or if deserializing through a base class reference.</div><br><blockquote type="cite"><div><blockquote type="cite">Another options is for the user to manually register his own<br></blockquote><blockquote type="cite">constructor with the serialization system prior unserializing, but<br></blockquote><blockquote type="cite">that's much less convenient.<br></blockquote><br>Agreed.<br><br><blockquote type="cite">The unserialize member function called above must be explicitly added<br></blockquote><blockquote type="cite">by the user (either manually or with a mixin) because the fields<br></blockquote><blockquote type="cite">don't reflect at runtime and the actual class is unknown at<br></blockquote><blockquote type="cite">compile-time. And the class needs to conform to an interface that<br></blockquote><blockquote type="cite">contains that unserialize function so we can find it at runtime.<br></blockquote><br>Yah, good point. Probably we'll need to add to the information emitted automatically by the compiler, but for starters, how about this:<br><br>class Widget : Serializable!Widget {<br> ...<br>}<br><br>Then Serializable would use compile-time introspection to figure out Widget's fields etc.<br><br><blockquote type="cite">So before adding a serialization library, I would suggest we solve<br></blockquote><blockquote type="cite">the runtime-reflection problem and find a standard way to attach<br></blockquote><blockquote type="cite">various attributes to types and members.<br></blockquote><br>If we go with the pattern I suggested above, we could even establish a naming convention for fields...<br><br><blockquote type="cite">That could be done as a<br></blockquote><blockquote type="cite">library, but ideally it'd have some help from the compiler which<br></blockquote><blockquote type="cite">could put this stuff where it really belongs: ClassInfo. Currently,<br></blockquote><blockquote type="cite">QtD has its own mixins for that, my D/Objective-C bridge has its own<br></blockquote><blockquote type="cite">mixins and class registration system, my serialization module has its<br></blockquote><blockquote type="cite">own, surely Orange has its own, I believe PyD has its own... this is<br></blockquote><blockquote type="cite">going to be a mess pretty soon if it isn't already.<br></blockquote><br>Not necessarily if it's in the standard library and if it facilitates everybody else's implementation and higher abstractions.<br><br><blockquote type="cite">Once we have a proper standardized runtime-reflection and attribute<br></blockquote><blockquote type="cite">system, then the serialization module can focus on serialization<br></blockquote><blockquote type="cite">instead of implementing various hacks to add and get to the<br></blockquote><blockquote type="cite">information it needs.<br></blockquote><br>I think we need to start with solid compile-time reflection and then look for ways to transport it to runtime, ideally using library facilities.<br></div></blockquote><div><br></div>Don't we already have quite solid compile-time reflection with __traits using hasMember and getMember? Now I don't understand how these could be transported to runtime. On the other hand we already have half of this implemented in the runtime in the form of ClassInfo.getMembers (though it currently doesn't work). We only need methods to set and get the value of a member. <span class="Apple-style-span" style="font-family: monospace; white-space: pre; "><br></span><br><blockquote type="cite"><div>Andrei<br>_______________________________________________<br>phobos mailing list<br><a href="mailto:phobos@puremagic.com">phobos@puremagic.com</a><br>http://lists.puremagic.com/mailman/listinfo/phobos<br></div></blockquote></div><br><div>
-- <br>/Jacob Carlborg
</div>
<br></body></html>