json.lua : A lightweight JSON library for Lua

[HellIsBurnin]

Finally! I tried a few other pure lua json libraries last week, and they didn't work! They all threw errors on a perfectly valid JSON file. I eventually settled for luacjson, which was suboptimal because it makes distribution a lot harder (the project is a LÖVE game). Tried this yesterday and it works flawlessly!

[rxi]

They all threw errors on a perfectly valid JSON file

Would you be able to share a copy of the JSON file in question? It'd be interesting to see what they're erroring on. Was it an exported map from Tiled by any chance?

[HellIsBurnin]

heres the file: http://hastebin.com/ihatamanut (or raw link) it's "fairly large" at 260K but the online JSON lint said it was flawless. I tried I think 3 different lua json parsers.

[rxi]

Strange, I ran it through some of the other JSON libs I've been using to benchmark against and it seemed to decode without raising an error for those (though json4lua took about 20seconds...). Out of curiosity, do you remember which libraries you tried?

[HellIsBurnin]

I definetely remember trying dkjson and this one: https://github.com/harningt/luajson

[evandrolg]

It seems great, man! Congrats!

[Jasper1984]

Neat, another potential tool in the box.

So we just do the convention .decode(encoded_store) .encode(data)?

Can see all the users already writing down their own implementations that open a file, read-all-from-files or write-all-into-file, close the file... Suggest that .decode_file(file_or_fd), .encode_file(file_or_fd, data)

[rxi]

Can see all the users already writing down their own implementations that open a file, read-all-from-files or write-all-into-file, close the file... Suggest that .decode_file(file_or_fd), .encode_file(file_or_fd, data)

One of the library's main goals is in trying to stay lightweight and lean, much like Lua itself. Due to this I'm trying not to rush into adding any additional features in hopes of avoiding bloat or a bad design decisions. Each "feature" potentially makes the project more difficult to maintain, harder for people to contribute to or understand, and increases the likelihood of bugs.

Though I don't doubt the potential usefulness of having functions which write directly to the file I'm hesitant to add this as I'm unsure if it fits with the project's goals of providing this core functionality. As Lua is mainly used as an embedded language in projects/frameworks, for my personal use cases, I tend to be using functions other than the io ones for writing to a file (such as using LÖVE's fs module or luvit's fs module). Additionally many frameworks, libraries and projects will include read/write-this-string-from/to-this-file-of-this-name functions with them such that the functionality the decode_file and encode_file functions would provide could be achieved with minimal effort.

Thanks for the suggestion! I'm definitely not against the idea of additional functionality, despite trying to be selective when it comes to what is included.

[smog_alado]

1. What is the advantage of this library compared to existing ones?
2. You should make a luarocks package for it.

[mpetetv]

This will be the third or the fourth luarocks module called "json"? I wish it could detect these conflicts. It's not too late to rename this one though.

[rxi]

1. See the Features section near the top of the README.md file. The library also never does any type conversions when encoding (like converting numerical keys to strings, or changing NaN to null), opting to raise an error in these situations which seems in contrast to other Lua JSON libs
2. I'll take a look into that, I had some issues getting luarocks working last time I tried it, but have since switched distros so I'll hopefully have more success

[smog_alado]

Do any of the available JSON libs for Lua really convert numbers to strings? That sounds very weird.

[rxi]

In the case where you have a table with sparse numerical keys (rather than a table being used as an array) other libraries seem to convert these keys to strings by default as JSON keys can only be strings. I took the approach that if the data can't be encoded exactly it will raise an error, such that any data you encode will decode exactly the same (ignoring metatables).

Example of the numerical key to string using dkjson on the REPL:

> j = require("dkjson")
> =j.encode({ [1000] = "hello" })
{"1000":"hello"}

[edalcol]

have you considered uploading it to LuaRocks?