enum versus uniqueItems in the 03 draft
Martijn Faassen
'uniqueItems' was modified in draft 03 to only define uniqueness for
primitive types, not array or object. I understood that the motivation
behind this was that in Javascript it is potentially expensive to
calculate whether an object or array item is identical to another. (in
Python the built-in == operator does this for you, but Javascript has
no equivalent).
I am wondering why then 'enum' still can still contain array or object
items. To check whether a value matches an entry in an enum, the same
check needs to be made. Granted the algorithmic complexity is less,
but if you need to implement "is the same" for object and array anyway
to support enum, it's easy enought to use it in uniqueItems as well.
Do we really want to worry about algorithmic complexity for
uniqueItems so much in the spec? It should be possible to devise more
efficient algorithms in Javascript as well, after all. Or is there
another motivation behind this change?
In addition I'm also wondering how to deal with uniqueness if arrays
and objects are in the array to be checked. Are they always considered
to be non-identical to each other? I think that's the intent, but I
think the current draft is not very clear on this with its 'only
defined for primitive types' language.
Regards,
Martijn
Gary Court
> Hi there,
>
> 'uniqueItems' was modified in draft 03 to only define uniqueness for
> primitive types, not array or object. I understood that the motivation
> behind this was that in Javascript it is potentially expensive to
> calculate whether an object or array item is identical to another. (in
> Python the built-in == operator does this for you, but Javascript has
> no equivalent).
>
> I am wondering why then 'enum' still can still contain array or object
> items. To check whether a value matches an entry in an enum, the same
> check needs to be made. Granted the algorithmic complexity is less,
> but if you need to implement "is the same" for object and array anyway
> to support enum, it's easy enought to use it in uniqueItems as well.
>
> Do we really want to worry about algorithmic complexity for
> uniqueItems so much in the spec? It should be possible to devise more
> efficient algorithms in Javascript as well, after all. Or is there
> another motivation behind this change?
"uniqueItems" is being updated to allow complex types.
> In addition I'm also wondering how to deal with uniqueness if arrays
> and objects are in the array to be checked. Are they always considered
> to be non-identical to each other? I think that's the intent, but I
> think the current draft is not very clear on this with its 'only
> defined for primitive types' language.
If would say that the rule would be:
An array is equal to another array if it contains the same number of
items, and each item in the array is equal to the corresponding item
in the other array.
An object is equal to another object if it contains the same property
names, and each property in the object is equal to the corresponding
property in the other object.
Martijn Faassen
On Sat, Nov 6, 2010 at 8:21 PM, Gary Court <gary....@gmail.com> wrote:
[uniqueItems not allowing complex types in current draft]
> "uniqueItems" is being updated to allow complex types.
Okay, good, I prefer being allowed to do comparisons between complex
types as this can be well defined with JSON.
>> In addition I'm also wondering how to deal with uniqueness if arrays
>> and objects are in the array to be checked. Are they always considered
>> to be non-identical to each other? I think that's the intent, but I
>> think the current draft is not very clear on this with its 'only
>> defined for primitive types' language.
>
> If would say that the rule would be:
> An array is equal to another array if it contains the same number of
> items, and each item in the array is equal to the corresponding item
> in the other array.
> An object is equal to another object if it contains the same property
> names, and each property in the object is equal to the corresponding
> property in the other object.
Yes. I had this implementation in Python, and then I realized ==
actually already does this for Python dictionaries (objects in JSON)
and arrays, and more quickly than anything I can write. :)
Regards,
Martijn