[Pharo-users] Is it bad to have an order NeoJsonObject?

Herbert Vojčík herby at mailbox.sk
Mon Jun 11 17:53:47 EDT 2018



Norbert Hartl wrote on 11. 6. 2018 23:38:
> 
> 
> Am 11.06.2018 um 16:48 schrieb Richard O'Keefe <raoknz at gmail.com 
> <mailto:raoknz at gmail.com>>:
> 
>> I'm really baffled here.
>> Look at the definition at json.org <http://json.org>.
>>
>> ​    An object is an UNORDERED set of name/value pairs.
>>
>> Or look at ECMA-404, which json.org <http://json.org> points to.
>>
>>     The JSON syntax does not impose any restrictions on
>>     the strings used as names ... and DOES NOT ASSIGN
>>     ANY SIGNIFICANCE TO THE ORDERING.
>>
>> When you say that "it is pretty clear that the order is
>> important for that format" I fail to understand you.
>> It is absolutely clear that by design the order is NOT
>> important or even significant for JSON.
>>
>> JSON Pointer does not provide any way to refer to order
>> in an "object":  /2 applied to an object will look for
>> the name "2" as a string.
>>
>> JSONPath does not provide any way to refer to order in
>> an "object":  [2] applied to an object will look for
>> the name "2" as a string.
>>
>> JSON Schema does not provide any way to constrain or
>> refer to order in an "object".
>>
>> As for databases, Postgres documentation says of JSONB
>> that "Insignificant whitespace is discarded, and
>> the order of object keys is not preserved."
>>
>> If you are communicating with someone else who is using
>> pseudo-JSON that does attach semantics to the order of
>> the name/value pairs, then of course you do whatever you
>> have to in order to communicate successfully.  Just don't
>> think of it as JSON.  If you have two programs whose
>> protocol you control, again you can use JSON syntax with
>> different semantics all you want.  Just don't think of it
>> as JSON.  Heck, if it is important to you to distinguish
>> between integer 1 and floating point 1.0, you can add
>> your own semantics if you like, but *JSON* doesn't
>> distinguish them.
>>
>> As for MongoDB, it works with BSON (which is richer than
>> JSON. which is why "MongoDB Extended JSON exists), and
>> does some seriously odd things, like regarding
>> {} and {"a": null} as equal.  (According to the 3.6 manual.)
>>
>> Do whatever you have to do to get the job done,
>> but just remember that most JSON tools think they are
>> dealing with *JSON*, not something else that looks
>> like it but has different semantics, and can be relied
>> on to preserve or respect *JSON* semantics, not some
>> other semantics unknown to them.
>>
> It was not talked about JSON but about a content format that uses JSON 
> as its encoding.  So if that format how poor it appears to use puts 
> significance to the ordering why you even start to argue?
> Why care about JSON tools and talk about semantics because there is no 
> semantic in an encoding format. It is an encoding format of nested keys 
> and values and arrays. No key or value has special meaning. It is dumb 
> JSON.
> You can use every JSON tool to read and destroy it. Like you can read a 
> binary file in a text editor apply newline conventions and destroy it.
> What is the point here?

I presume the point here is that, if you presume JSON is mostly used 
with JavaScript, then JSON _is_, in effect, keeping the order. If I am 
not mistaken, it is already part of the spec a few years already that 
enumeration on the object keys MUST respect the order in which keys were 
created, and JSON algorithm prescribes that keys are created in the 
order they are read when parsing, and should use the internal order of 
keys when stringifying. So, JSON is de facto preserving order, though de 
iure it is not. But the fact that is does it de facto, leads to creation 
of order-dependent services. Not saying this is correct per specs, not 
that it is correct from general design PoV, just that it happens because 
order preserving _is_ already there, so the code may end up using it, 
even unconsciously.

This "JSON is in practice order-preserving" implementation artifact then 
leaks out when some protocols end up requiring it.

Then other languages may feel the need to have this "industry standard" 
of order-preserving JSON to have as well.

OP correct me if I am wrong.

Herby

> Norbert



More information about the Pharo-users mailing list