Re: additional json functionality

On 14/11/13 11:33, Andrew Dunstan wrote:
>
> On 11/13/2013 04:58 PM, Merlin Moncure wrote:
>> On Wed, Nov 13, 2013 at 1:25 PM, Andrew Dunstan <andrew(at)dunslane(dot)net>
>> wrote:
>>> On 11/13/2013 11:37 AM, Merlin Moncure wrote:
>>>> Yes. and I think this is one of the major advantages of the json API
>>>> vs hstore: you can serialize objects that hstore cannot -- at least
>>>> not without extra scaffolding (at least, AIUI, I haven't fully
>>>> grappled with the coming hstore stuff yet). In other words, just
>>>> because key order and cardinality is unimportant in an associative
>>>> array, it does not in any way follow it is similarly unimportant for
>>>> object serialization.
>>> An object is an unordered collection ofz ero or more name/value
>>> pairs
>>> ...
>>>
>>> The names within an object SHOULD be unique.
>>>
>>> Forcing us to preserve order and key duplication would be a pretty
>>> effective
>>> barrier to any performance improvements.
>> SHOULD != MUST. Here is the definition of object per RFC 4627.
>>
>> "An object structure is represented as a pair of curly brackets
>> surrounding zero or more name/value pairs (or members). A name is a
>> string. A single colon comes after each name, separating the name
>> from the value. A single comma separates a value from a following
>> name. The names within an object SHOULD be unique."
>>
>> And SHOULD means
>> "3. SHOULD. This word, or the adjective "RECOMMENDED", mean that
>> there may exist valid reasons in particular circumstances to ignore a
>> particular item, but the full implications must be understood and
>> carefully weighed before choosing a different course."
>>
>> As far as I'm concerned, that settles things right there. Beyond that
>> (although they do say 'unordered' above), as a consequence of your
>> argument the json strings {"a": 1, "b": 2} and {"b": 1, "a": 2} should
>> be considered equivalent. Another consequence is that creating
>> particular legal constructions should be discouraged. I disagree with
>> this.
>>
>> This is simply not the case with many json consuming clients. It's a
>> nice idea but not how things work universally and that's exactly why
>> the rules were hedged in the RFC. I have a couple of cases right now
>> where I'm producing key order sensitive json for some (admittedly not
>> very well designed) json consuming clients that are out of my control.
>>
>
>
> I understand the difference between "should" and "must". But there is
> nothing that REQUIRES us to preserve key order or duplicate keys. If
> you really need textual preservation, you should probably store the
> data as text and convert it to json to do json-ish things to it. If
> not, we're going to face huge demands to implement another type which
> almost everyone but you will move to in rapid order because it
> performs so much better. The strong consensus I have seen in
> discussions at conferences and elsewhere is to go the way we're going,
> instead.
>
> cheers
>
> andrew
>
>
>
I can see that both points of view are valid, in different contexts.

Would be possible to have a boolean, such as 'strict' - so that unique &
ordered was only imposed when strict was TRUE? Alternately, separate
functions to allow the same choice?

Cheers,
Gavin