lua-users home
lua-l archive

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

By the way, lua-yajl is still actively maintained (version 1.2
contains a memory leak fix for to_value).  Patches are welcomed :-).

Thanks for posting the comparison wiki page.  I notice the "protection
against bloated arrays when encoding" section.  Does this mean that
people desire for this:

  {[1000] = "harhar"}

To be encoded as this?


Instead of encoding it as:


If this is desired, then I could add support for this in lua-yajl.

Some other interesting things to compare is how the various
implementations deal with null since mapping a JSON null to Lua nil
has the side-effect of making it so that there is no way to express a
JSON "object" that has a null value, and there is no way to express a
JSON array with nulls on the end:

  {"foo": null}
  ["foo", null]

Another interesting comparison is if the various implementations allow
custom "serializers" that allow userdata or lua "objects" to specify
how the lua implementation can be translated into JSON.  The lua-json
implementation supports this sort of custom "serialization" via the
__gen_json meta-method.

Also, if someone desires lua-yajl to be a lua rock, simply propose a
rock spec... however lua-yajl currently depends on the yajl C library
which currently uses CMake, so I wonder if this might be of limited


On Sat, Aug 28, 2010 at 1:43 PM, David Kolf <> wrote:
> Hi,
> I have written a JSON module implemented in pure Lua without
> dependencies to other external libraries. It supports UTF-8.
> The file is called dkjson.lua to avoid conflicts with other JSON modules
> that already exist. It doesn't write any global variables, so you can
> give it any name you want when you use require.
> I have put a comparison of different JSON modules for Lua known to me in
> the wiki:
> In summary Lua-YAJL appears to be the best, the few disadvantages I
> found should be more or less easy to patch.
> For Lua-only modules my version appeared to me to be the best, both
> regarding speed and compatibility to the standard.
> Today I learned how to use the LPeg module and in my local test version
> of dkjson I already added optional support for it. The speed up for
> decoding is significant, so I will probably release a version 2.0 soon.
> -- David

Brian Maher >> Glory to God <<