Standards for JSON decoders

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Standards for JSON decoders

Dirk Laurie-2
Is the Lua representation of JSON reasonably standard across decoders
by now? The one I use [1] translates integers to integers; floats to floats;
strings to strings; arrays and objects to tables, distinguished by
their metatables. There is one metatable for all JSON objects and
another for all JSON arrays. Those metatables are not functional,
they merely contain fields that identify to which JSON type the table
corresponds.

Do other JSON decoders do this differently?

[1] rapidjson

Reply | Threaded
Open this post in threaded view
|

Re: Standards for JSON decoders

Sean Conner
It was thus said that the Great Dirk Laurie once stated:
> Is the Lua representation of JSON reasonably standard across decoders
> by now? The one I use [1] translates integers to integers; floats to floats;
> strings to strings; arrays and objects to tables, distinguished by
> their metatables. There is one metatable for all JSON objects and
> another for all JSON arrays. Those metatables are not functional,
> they merely contain fields that identify to which JSON type the table
> corresponds.
>
> Do other JSON decoders do this differently?

  For Lua 5.3, my own JSON decoder [2] returns integers as integers, floats
as floats and arrays and objects as tables sans a metatable.

  -spc

> [1] rapidjson

[2] https://github.com/spc476/LPeg-Parsers/blob/master/json.lua

Reply | Threaded
Open this post in threaded view
|

Re: Standards for JSON decoders

Dirk Laurie-2
2017-06-15 17:42 GMT+02:00 Sean Conner <[hidden email]>:

>
> It was thus said that the Great Dirk Laurie once stated:
> > Is the Lua representation of JSON reasonably standard across decoders
> > by now? The one I use [1] translates integers to integers; floats to floats;
> > strings to strings; arrays and objects to tables, distinguished by
> > their metatables. There is one metatable for all JSON objects and
> > another for all JSON arrays. Those metatables are not functional,
> > they merely contain fields that identify to which JSON type the table
> > corresponds.
> >
> > Do other JSON decoders do this differently?
>
>   For Lua 5.3, my own JSON decoder [2] returns integers as integers, floats
> as floats and arrays and objects as tables sans a metatable.

That decodes JSON '[]' and JSON '{}' to inditinguishable Lua tables.
I presume you only decode, not encode too?

Reply | Threaded
Open this post in threaded view
|

Re: Standards for JSON decoders

Sean Conner
It was thus said that the Great Dirk Laurie once stated:

> 2017-06-15 17:42 GMT+02:00 Sean Conner <[hidden email]>:
> >
> > It was thus said that the Great Dirk Laurie once stated:
> > > Is the Lua representation of JSON reasonably standard across decoders
> > > by now? The one I use [1] translates integers to integers; floats to floats;
> > > strings to strings; arrays and objects to tables, distinguished by
> > > their metatables. There is one metatable for all JSON objects and
> > > another for all JSON arrays. Those metatables are not functional,
> > > they merely contain fields that identify to which JSON type the table
> > > corresponds.
> > >
> > > Do other JSON decoders do this differently?
> >
> >   For Lua 5.3, my own JSON decoder [2] returns integers as integers, floats
> > as floats and arrays and objects as tables sans a metatable.
>
> That decodes JSON '[]' and JSON '{}' to inditinguishable Lua tables.
> I presume you only decode, not encode too?

  JSON decode only.  When I wrote the CBOR module [1][2], I used a huristic
to encode a Lua table as an array or a map (what JSON calls an object) [3].
Of course that can be overriden by the user with supplying a __tocbor()
metamethod.

  For decoding, I didn't bother with distinguishing a map vs. an
array---you'll get a Lua table and it's up to the user to know if it should
be a map or an array (that was my thought anyway).  And again, if you want
such a distinction, you can do it (by supplying an optional conversion
function called during the decoding process).

  -spc (Who likes CBOR over JSON)

[1] https://github.com/spc476/CBOR

[2] Think of CBOR as a superset of JSON.  It allows semantic tagging of
        data, which allows for things like dates (a few formats) or even
        circular references (so you can encode a table defined as "x = {}
        x[x] = x").

[3] https://github.com/spc476/CBOR/blob/cb11a9c32f742a8b369a9b8d07bea9a2fa68879a/cbor.lua#L1303