lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 



On 06/10/15 04:07 PM, Thijs Schreijer wrote:

   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.

/s/ Adam

If that were implemented, now how would my code know which of those it would need to call? Just `__serialize` should do.

It should either return plain Lua values with no recursion (as mentioned earlier), or simply a string. Though the latter option might have everybody reinventing the serialization, whilst some good libraries are available, so I would prefer the former.

A second return value can be added to identify the type. Even if that type might be prone to collisions, a recent remark in the thread about the usefulness of the registry asked for any cases where there were collisions in the registry. I didn't see any response on that. So I don't think it to be such a big issue.
Just setting some proper examples with namespacing should set people of in the right direction.

So for the LuaDate library I'm maintaining, something like "lua:thijsschreijer.nl/luadate/1.0" would be a fine type name I guess.

Thijs

How about this:

__serialize(object, recursive) --> return newobject, raw, type
raw is a boolean, if it's true and newobject is a string, it should be used as-is. if it's true and newobject is NOT a string, it... uhh... it could error? if it's false newobject is a pre-serialized object and you just pass it through your own serializer, which can be iterative or recursive. (both iterative and recursive serializers can handle recursion.)
recursive indicates whether the serializer handles recursion or not. it defaults to a false value. all __serialize must support non-recursive serializers. a __serialize should support recursive serializers. returning a recursive newobject to a non-recursive serializer must error.
type is just a hint for serializers on how to serialize the newobject. it should be ignored if raw is true. 

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.