lljson.slencode()/sldecode() don't work well with lljson.empty_array
complete
SuzannaLinn Resident
lljson.empty_array
decodes to an empty table:local t = { lljson.null, lljson.empty_array }
print(t[1], t[2])
-- > lljson_constant: 0x0000000000000003 lljson_constant: 0x0000000000000005
local s = lljson.slencode(t)
print(s)
-- > [null,[]]
local ts = lljson.sldecode(s)
print(ts[1], ts[2])
-- > lljson_constant: 0x0000000000000003 table: 0x0000000011ef6718
lljson.slencode()/sldecode()
should be able to recover the exact same table.Log In
H
Harold Linden
marked this post as
complete
This is now live on the beta grid
H
Harold Linden
marked this post as
in progress
We don't use
lightuserdata
s for things like lljson.empty_array
anymore, Should make this a lot less painful.sldecode()
doesn't even attempt to pretend that it retains "array-ness" or "object-ness" by default, and encodes tables however fits best in the payload.Tapple Gao
Tapple Gao
I'd rather have
lljson.decode("[]") -- > setmetatable({}, lljson.array_mt)
lljson.sldecode("[]") -- > setmetatable({}, lljson.array_mt)
In case I want to
table.insert
on the currently empty array to make it a non-empty array and re-encode it, still as a json array:> t = lljson.decode("[]")
> table.insert(t, 5)
> lljson.encode(t)
[5]
Wait. this actually already works (it also works with
sldecode
/slencode
). Then, why does this print nil
? It should print table: 0x000000002416d7c8
for all 3 expressions:> lljson.array_mt
table: 0x000000002416d7c8
> getmetatable(lljson.decode("[]"))
nil
> getmetatable(lljson.sldecode("[]"))
nil
I specifically don't want
lljson.decode("[]')
to return lljson.empty_array
, because:> table.insert(lljson.empty_array, 5)
stdin:1: invalid argument #1 to 'insert' (table expected, got lljson_constant)
stack backtrace:
[C] function insert
stdin:1
SuzannaLinn Resident
Tapple Gao
lljson
doesn't encode the metatable, a decoded table always has getmetatable(t) == nil
Tapple Gao
SuzannaLinn Resident yes, that's what it does today. But, this is a bug report. I'm describing desired behavior. And, my desire is that tables produced by
lljson.decode
and lljson.sldecode
have a metatable of either lljson.array_mt
or lljson.object_mt
H
Harold Linden
marked this post as
planned
H
Harold Linden
Interesting! in general, it's probably best for us to avoid the hacks necessary for normal JSON serialization by not treating them specially at all in the serializer, and not decoding them in the deserializer. Since they're a lightuserdata, I'll have to think of a serializer that makes sense there without letting people create any arbitrary lightuserdata.