-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
selector syntax #5
Comments
Asking around, having this sugar... [">", ".foo", 0] ...was universally loved ❤️ |
Lifting some conversation from DMs here:
|
UPDATE: that's not what {foo: [0,1,2,3,4,5]}
.foo[1:3] // ..., [1,2,3], ...
.foo[1:3][] // ...1, 2, 3, ... The refrain in feedback in basically any community I've asked is "just do what jq does unless you have a good reason not to", so let's respect jq behaviour here 👍 |
I have implemented selectors and put together this test vector so we could utilize it for compatibility Few things I'd like to call out
I think it would be a good idea to not follow jq blindly and make things bit more consistent. E.g. always result in |
Some more WTF from jq land echo '{}' | jq '.q[0]'
> null
echo '{"q": {"0":1} }' | jq '.q[0]'
jq: error (at <stdin>:1): Cannot index object with number
echo '{}' | jq '.[][][][]'
echo '{"q":{}}' | jq '.[][][][]'
echo '{"q":{"x":1}}' | jq '.[][][][]'
jq: error (at <stdin>:1): Cannot iterate over number (1) |
LOL yeah I don't love their heavy use of null. I guess they're using null as undefined?
If you use quotes it works: $ echo '{"q": {"0":1} }' | jq '.q["0"]'
1 Which is maybe a fine enough way to distinguish between array index vs maps? I'm not against that behaviour being explicit, though I would have expected it to returning the first alphabetical element of a collection on a map 🤷♀️ This one seems reasonable to me, and IIRC matches how JS behaves |
😆 wut |
Do you mean like this? // {a: 1}
".b" == null I guess that makes sense. We want to be able to say that somethnig is unset. Do we need to distinguish between these cases in validators? query = ".a"
{a: null}
// null
query = ".a"
{}
// null |
Agreed 👍
Seems reasonable. From the chat in Discord, it probably needs to extend with some/every, but it's basically right yeah 👍
I think I see why: it looks identical to expecting a map key. |
I don't like this but it is jq behavior
These behave as follows in jq, I don't like it but it does
|
JSON does not have |
In JS it will cast |
How do you feel about this behaviour: // {}
["not", ".foo"] // true
// {foo: null}
["not", ".foo"] // true
// {foo: false}
["not", ".foo"] // true Which is a bit more like JS |
(specifically trying to find a way to predicate omission) |
Yeah they fail on some (what I think they're treating as) type errors, but not others |
I would personally leave not to logic operators and leave selectors out of it you could instead use |
Which I guess is an advantage of missing keys matching |
I had a typo I meant |
I don't like that jq returns null when you don't have a corresponding element, I would personally prefer error there. That way adding |
Yes that's the behaviour in jq 👍 That works for my use case above :)
Yeah that makes a lot of sense. I do think that sticking fairly closely to jq is still a good idea, and having a CLI tool to test things against has been helpful even in this thread. IMO we can diverge from their behaviour where there's a good reason. Let's maybe draft a bullet point list on how we'd like to diverge from them? |
Turns out jq utilized
|
The "Optional Array Key" row in the "Supported Forms" table above is missing a |
The "Supported Forms" table used as testcases in |
## Supported forms testing This PR provides a set of testcases to verify that the `Selector` behaves properly according to the "Supported Forms" table proposed in a GitHub issue at ucan-wg/delegation#5 (comment). The test cases are divided into three groups: - Tests that should return one or more IPLD `datamodel.Node`s - Tests that should return "null" which is currently replaced by `nil` in Go - Tests that should return an `error` Currently all the `nil` and `error` testcases pass. There are ten `node` testcases that are failing with two having obvious causes: 1. The "Negative Index" test properly `Parse`s the `Selector` text but fails with an `index out of range [-1]` panic when `Select` is called. 2. The "Optional Iterator" test returns the expected values but also a `nil` value for the second element which isn't a `List`. This should probably be pruned during `Select`.
Here is my best attempt to describe jq inspired selector syntax and deliberate incompatibilities with jq.
Supported Forms
.
{x:1}
{x:1}
{x:1}
.[]
[1, 2]
1, 2
(1, 2)
.[]
null
.[]?
null
()
()
.[][]
[[1], 2, [3]]
(1, ⛔️)
.[][]?
[[1], 2, [3]]
(1, 3)
(1, 3)
.x
{ x: 1 }
1
1
.x
{}
null
.x?
{}
null
null
.x
null
null
.x?
null
null
null
.x
[]
.x
[]
null
null
.["x"]
{x: 1}
1
1
.["x"]?
{}
null
null
.length
[1, 2]
.length?
[1, 2]
null
null
.[0]
[1, 2]
1
1
.[4]
[0, 1]
null
.[4]?
[0, 1]
null
null
.[-1]
[1, 2]
2
2
.[0]
"Hi"
"H"
.[0]
Bytes([0, 1])
0
.[0:2]
[0, 1, 2]
[0, 1]
[0, 1]
.[1:]
[0, 1, 2]
[1, 2]
[1, 2]
.[:2]
[0, 1, 2]
[0, 1]
[0, 1]
.[0:2]
"hello"
"he"
"he"
.[1:]
Bytes([0, 1, 2])
Bytes([1, 2])
We treat bytes as u8 array. We also treat links as u8 array from selectors point of view.
The text was updated successfully, but these errors were encountered: