lljson.slencode/sldecode don't round-trip nil | Voters

lljson.slencode/sldecode don't round-trip nil

planned

Tapple Gao

Unsure how important this is, but putting it out there:

scalar doesn't work:

> t = nil
> print(t)
nil
> t = lljson.sldecode(lljson.slencode(t))
> print(t)
lljson_constant: 0x0000000000000003

array doesn't work:

> t = {nil, 2, nil, 4}
> for i, v in t do print(i, v) end
2       2
4       4
> t = lljson.sldecode(lljson.slencode(t))
> for i, v in t do print(i, v) end
1       lljson_constant: 0x0000000000000003
2       2
3       lljson_constant: 0x0000000000000003
4       4

dict works:

> t = {a=2, b=nil}
> for i, v in t do print(i, v) end
a       2
> t = lljson.sldecode(lljson.slencode(t))
> for i, v in t do print(i, v) end
a       2

I don't anticipate running into this the way I plan to use

slencode

with LinksetData. There, I'll convert scalar nil to/from "" and never include nil in arrays.

But, maybe someone else can think of a reason to do something different with one or more of these usecases

2 days ago

Harold Linden

marked this post as

planned

SuzannaLinn Resident

There is a github issue about it here: https://github.com/secondlife/slua/issues/43

currently

nil

is encoded as

lljson.null

Tapple Gao

hmm. I thought

sldecode

could just turn

lljson.null

back into nil. But supporting both would work too. I don't see a strong reason for

slencode

sldecode

to handle anything that isn't a slua builtin type. I think of

lljjson.null

as only for

encode

decode

, for interfacing with non-sl API's. And

slencode

sldecode

for when you control both ends of the communication, and both ends are slua scripts