Should we provide for structured types in containable?

[cabo]

#125 (comment)

[goessner]

After thinking a while about comparing structured types, I now see no problem to support equality of them. I agree to handling them is straightforward:

Two structured types are equal, if they are equal on a per-node basis.

also see The Abstract Equality Comparison Algorithm ... not exactly, what we want though.

We need to be clear about order ... !

[1,2] == [1,2]
{x:1,y:2} == {x:1,y:2}
[1,2] == [2,1]  // ?
{x:1,y:2} == {y:2,x:1} // ?
[] == []
{} == {}

Containables may be defined on exactly that comparison rule.

I believe, we need to add objects here again. Also we need to discuss subsets.

Array Examples:

1 in [1,2,3]             // primitive value lhs
[1,2] in [1,2,3]         // structured value lhs
[1,2] in [1,2,3,[1,2]] // subset
[] in [1,2,3]             // empty array
[] in [1,2,3,[]]          // empty array
{} in [1,2,3,{}]          // empty object
{x:1,y:2} in [{x:1,y:2}]

Object Examples:

'x' in {x:1,y:2}
['x','y'] in {x:1,y:2}
{x:1} in {x:1,y:2}
{z:3,x:1} in {x:1,y:2,z:3}
{} in  {x:1,y:2}

Once having agreement about handling that edge cases (maybe there are more), we might add it to the spec.

Btw.: JavaScript resolves all comparisons above to false, since objects are equal only, if they are referencing the same object (no deep equals).

[glyn]

Comments inline.

On Tue, 2 Nov 2021 at 11:48, Stefan Goessner ***@***.***> wrote: After thinking a while about comparing structured types, I now see no problem to support equality of them. I agree to handling them is straightforward: Two structured types are equal, if they are equal on a per-node basis. also see The Abstract Equality Comparison Algorithm <https://262.ecma-international.org/5.1/#sec-11.9.3> ... not exactly, what we want though. We need to be clear about order ... ! [1,2] == [1,2] {x:1,y:2} == {x:1,y:2} [1,2] == [2,1] // ? No. Arrays are ordered and equality tests should respect that ordering. {x:1,y:2} == {y:2,x:1} // ? Yes. Objects are unordered and equality tests should respect that lack of

ordering.

[] == [] {} == {} Containables may be defined on exactly that comparison rule. I believe, we need to add objects here again. Also we need to discuss subsets. Array Examples: 1 in [1,2,3] // primitive value lhs [1,2] in [1,2,3] // structured value lhs No. Conflating membership and subset violates the principle of least

surprise and so is likely to cause confusion. Also I am not aware of any precedent for such conflation in mathematics or programming language semantics.

[1,2] in [1,2,3,[1,2]] // subset This doesn't add any value beyond the previous case. Better to discuss:

[1,2] in [[1,2]] // structured value membership Also, we need to discuss ordering of arrays. For example: [1,2] in [[2,1]] should be false, if we agree that [1,2] != [2,1].

[] in [1,2,3] // empty array [] in [1,2,3,[]] // empty array {} in [1,2,3,{}] // empty object {x:1,y:2} in [{x:1,y:2}] Object Examples:

I don't think we should conflate membership and subset. Since "in" has a stronger connotation of membership than subset, I don't think we can easily define "in" with an object on the right hand side. Note also that there isn't yet a notation for a mathematical "maplet", but if we represented it as a pair, e.g. ('x',1), then we could test membership of objects thus: ('x',1) in {x:1} (However, I don't think this is worth the cost of increased complexity of the spec.)

…

'x' in {x:1,y:2} ['x','y'] in {x:1,y:2} {x:1} in {x:1,y:2} {z:3,x:1} in {x:1,y:2,z:3} {} in {x:1,y:2} Once having agreement about handling that edge cases (maybe there are more), we might add it to the spec. Btw.: JavaScript resolves all comparisons above to false, since objects are equal only, if they are referencing the same object (no deep equals). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#127 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAXF2J2TDFR5P3LGOZ4QH3UJ7FX3ANCNFSM5GVV2MMA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[goessner]

I totally support a decision to:

• not dealing with subsets
• restrict the rhs to arrays only

with contain-expr's.

[cabo]

We decided not to have " in ", so this is now closed/revisit-after-base-done.

[gregsdennis]

I've supported this with configuration. You can play with it at https://json-everything.net/json-path.