Re: The hypothetical __serialize metamethod (was Re: [ANN] luaproc 1.0-4)

Perhaps this serialization metamethod would be responsible for serializing the data into "plain-old-lua" format. One could potentially add a restriction that if it is a table is must be a 'simple' table (no self-referencing entries/etc) or perhaps keys must be 'simple' values (boolean, number, string).

This would yield something that serialization tools could use to distill the data into a format they can handle w/o inventing ways to handle recursion/etc. One tricky bit that could make this useless, depending on the implementation use case, ... how does one de-serialize in a useful manner? It would seem the deserialization tool would need to know the inverse to construct the object - yielding a need to serialize type information possibly... and that's somewhat of a rats nest.

On Tue, Oct 6, 2015 at 1:16 PM Sean Conner <sean@conman.org> wrote:

It was thus said that the Great Andrew Starks once stated:
> On Tue, Oct 6, 2015 at 11:12 AM, Rena <hyperhacker@gmail.com> wrote:
> > I think you could use a __serialize metamethod here, when you don't have a
> > built-in handler. Then userdata, magic tables and other objects could define
> > handlers as easily as they do other metamethods.
>
> I've often used __tostring for this, but then that wrecks my (often
> needed) method for pretty printing. I'm also guilty(?) of using two
> underscores, which I believe is, by documentation (?), reserved for
> the language. But I do it too...
>
> Overall, however, a serialize metamethod has been my preferred way of
> figuring this stuff out. We also found ourselves wanting to know if
> the message was going inter-process or just inter-thread, but that's
> too fancy for this purpose.

But wouldn't there have to be a consensus as to *what* __serialize
returns? I mean, obviously, a string of byte values (variation on a string)
but the actual contents can vary widely. Given a simple Lua table:

{ 1 , "two" , true }

One person might want to serialize that as JSON:

[ 1 , "two" , true ]

Someone else might want BSON [1] (hex dump follows):

13 00 00 00 04 00 0D 00
00 00 30 00 01 00 00 00
31 00 74 77 6F 32 01

Another one (like me) might want to serialize to CBOR [2] (hex dump
follows):

83 01 63 74 77 6F F5

and yet another might want straight up Lua:

{ 1 , "two" , true }

Is it better to perhaps just reserve "__serialize" for serialization and
leave it up to modules to flesh it out? Or do we need to actually define
the output format?

-spc (Not a proposal, just something to talk about ... )

[1] http://bsonspec.org/spec.html

[2] RFC-7049