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

[Coda Highland <chighland@...>]

On Tue, Oct 6, 2015 at 10:44 AM, Sean Conner <sean@conman.org> wrote:
> It was thus said that the Great Coda Highland once stated:
>> On Tue, Oct 6, 2015 at 10:15 AM, 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
>> >
>>
>> Solution: Don't call it __serialize! Call it __json, __bson, __cbor,
>> or whatever's actually appropriate for the format.
>>
>> You could borrow a Pythonism and use __repr for Lua syntax.
>
>   I actually like this idea, but it's unclear whether we can use those
> names.  I checked the Lua manual (5.3) and the only thing Lua reserves are
> the keywords
>
>      and       break     do        else      elseif    end
>      false     for       function  goto      if        in
>      local     nil       not       or        repeat    return
>      then      true      until     while
>
> and any itentifier with the following pattern:
>
>         '_' [A-Z]*
>
>   There's no mention of Lua reserving any identifiers with '__' (two
> underscores).
>
>   -spc

If you're worried about a collision with some future PUC-Rio extension
to the language, then call it "serialize_json" or something instead of
using __ as a prefix. It can still be stored in the same place on the
metatable.

/s/ Adam