El vie., 22 feb. 2019 a las 18:24, Sven Van Caekenberghe
(<s...@stfx.eu>) escribió:
>
> Good catch.
>
> Indeed, JSON keys have to be strings.
>
> The question is, should the writer convert them for you, or should you simply
> not use them ?
>
> I mean, there are many Pharo constructs that cannot be converted to JSON.
>
> Some could be output to JSON, but you won't be able to read them back in.
> So, if conversion would happen, the dictionary with integer keys will be read
> back with strings keys.
This is the same as with any object, you can serialize any object to a
JSON object ({"foo": "baz"...}), but you can't read it back UNLESS you
know exactly what to convert it to.
Maybe there should be an "integer" mapping that converts the number in
string representation back to an Integer when deserializing it.
> In STON, keys can be anything, even complex objects, like in Pharo itself.
That's why STON is better. :)
> What will you do with { (1@2)->100 } asDictionary in JSON ?
That is not valid JSON and not even JS. I mean, AFAIU in JS properties
are also strings, even array indices.
Try to do this:
> JSON.stringify({{x: 1, y: 2}: 100})
And it will fail.
E.g.
> point = {x: 1, y: 2};
> object = {point: 100}
> object
< {point: 100}
There the "point" is a literal, not a variable reference.
But if instead you do
> point = {x: 1, y: 2};
> object = {}.
> object[point] = 100;
> object
< {[object Object]: 100}
you get a frankenstein because the key got converted to a string:
> Object.keys(obj)
< ["[object Object]"]
The issue here is that the JSON writer creates invalid JSON syntax.
So it's either JSON (valid) or it's something else.
Not that I'm a fan of this, but I got bitten when submitting a
document to CouchDB which got rejected because of this invalid syntax.
To make things worse:
> object = {1: 'foo'}
> object[1]
< "foo"
> object["1"]
< "foo"
WAT! [1]
> I have to think about this.
Food for thought for the weekend.
Regards,
[1] https://www.destroyallsoftware.com/talks/wat
Esteban A. Maringolo
