Just like how there's a textutils.serialiseJSON, it would be useful to have a textutils.deserialiseJSON. This would come in handy in use together with the HTTP API, since a lot of web APIs return JSON responses.

You can use JSON APIs for CC. There are many, so I won't link one, but just search "json" on the forums and you'll find some.

There ARE user-written deserialisers, though to be fair, I haven't found one that works 100%.

It doesn't help that the reason "serialiseJSON" is there in the first place is for Minecraft command support, and some Minecraft commands use a bodgy version of JSON called a "data tag" - the main difference between the two is that JSON requires quotes around key names, and data tags require them to be absent.

textutils.serialiseJSON supports both formats, so it'd be logical that a proper textutils.deserialiseJSON would need to be coded with the same support (were it to be written at all).

Why not implementing the google json (gson) api. It is able to do things like that.

IIRC Minecraft uses gson anyways, so it wouldn't add any extra dependencies.

The problem is that textutils is implemented on the Lua side.

@apemanzilla @Janrupf Sadly even GSON doesn't support the full range of JSON that some Minecraft commands (such as /entitydata) generate. Namely the number type suffixes (so 12b to represent a byte). We'd have to roll our own parser on the Lua side, which is probably the way to go anyway.

I think it'd be a better idea to give access to gson methods, and having a separate Lua-side method for "Minecraft JSON"

The formats are similar enough that having support for both in the Lua-side API wouldn't require much more code than for just one. So even putting aside the whole "textutils is Lua-side" issue, there's not all that much point in using gson for anything if it can't be used for everything.

On the other hand, gson might be able to handle everything. Gamepedia reckons data tags are "a lenient form of JSON", but the method linked indeed doesn't claim to handle the suffixes SquidDev mentioned, so it may well just be wrong about that.

I wouldn't be surprised if it could, Gson is very powerful and very customizable.

If somebody writes a good version of this and PR's it, i'll probably merge it.