After reading through this (and related) threads, my personal opinions are: 1. __serialize should return a Lua function (with no upvalues) or code string to recreate the object. That could include eg loops and control flow to deal with recursion. (If you want to unserialize untrusted data, you have a different problem that probably is best handled by an application-specific system.) You're free to dump() the resulting function to a file and load() it later. 2. A __serialize method shouldn't necessarily be a "standard" metamethod (with a particular signature and operation described in the Lua manual), but if someone decides to implement it in their objects, it'd be helpful if it followed a simple interface (such as described above). 3. A __tojson method might be nice too, and serializers could certainly use it. 4. My phone keyboard needs to smarten up. Notice I'm not using the P-word here :) just throwing ideas at the wall to see what sticks.
— How to identify the de-serializer for each type (and avoid collisions)? — What happens if a de-serializer is missing? — How to handle different versions (that is, as the formats and pack/unpack code evolves over time)? — How to handle (and *who* handles) recursive structures and containers? — If you serialize as binary, how to handle different representations on different platforms — If you serialize as text, how to handle encoding, particularly for edge cases (e.g. NaN, non-exact floating point as decimal etc etc)
.. and there are many others. Several of our major projects *do* share a common serialization format, but it’s strictly Lua-to-Lua so we can make some assumptions because we carefully restricted the usage domain.
An __serialize standard isn’t going to help unless it can be plugged into a framework that has answered the above issues imho.
—Tim
|
