There is an intrinsic order in the text though. it's up to the parser to keep clobbering a value every time a new value comes in for a given key.

This seems like a bad idea. It seems heavily reliant on edge case behavior. But hey, might work well for the original author.

> it's up to the parser to keep clobbering a value every time a new value comes in for a given k

Nope, parsers are perfectly in their rights to do whatever they want with multiple keys. They could read them backwards, sort them, whatever. The behaviour in the instance of multiple keys is undefined.

> This seems like a bad idea.

It is an astonishingly bad idea. I'm concerned by it being so high on the page.

> But hey, might work well for the original author.

Depends on their parser. It's undefined behaviour according to the spec. It might work now, but I'd argue it doesn't work well, as a patch level change could bork this.

I'm not so sure. I think, JSON falls back to the ecma script standard for specific details. The object initializer semantics seem to force a left to right evaluation order, in the ecma spec around page 65. I'll admit my claim was unfounded when i made it, and I only went to the spec to avoid being wrong :) If I were to implement a JSON parser, I would now feel obligated to eval in order, due to my reading of the spec.

However, I think we wholeheartedly agree, don't rely on this behavior. It is an outright strict mode error.

while this is true, I think it's irrelevant: the "trick" is about "abusing"

* the fact parser work from top to bottom of the text

AND

* the fact that assigning the same key many times with different values update the key with the last value

your quote regards the order in witch the different keys are saved.

Both are only "correct" for specific implementation, this is not specified behavior (and duplicate keys is strongly recommended against by the key)

absolutely. This is nothing more than a clever trick, but I would never rely on it.

Honestly, tough, I think all major JSON parser behave following the two assumption.

streaming parsers can't follow the assumption short of becoming useless. They're either going to send only the first instance or going to send two different events.