Hi,
If you have for example:
[
{a: 1, b: 2, c: 3},
{a: 4, b: 5, c: 6},
{a: 7, b: 8, c: 9},
]
Is it possible to jsonselect match it to:
[
{b: 2, c: 3},
{b: 5, c: 6},
{b: 8, c: 9},
]
If its not possible ( I cant see how at the moment... ) could it be
possible?
I tried selecting ".b, .c" but I understand thats wrong ( and your not even
garunteed to get "[.b, .c]" but possibly "[.c, .b]" )
Thanks!
Dunk
Hi! gosh, that's an interesting case. No, this is not possible in jsonselect right now. Nowhere in jsonselect right now are values changed or filtered in any way. What you're really asking for here is that ability. One could imagine the addition of two new functions: :filter() and :include() (names might be wrong). The would work like this: :filter(S) - when applied to the last selector in a sequence, contains a selector that will be applied against matching objects. any nested values that match said selector will be removed. :root > object:filter(.a) or equivalently: object:filter(.a) or :root > :filter(.a) The :include() pf would be the opposite. so it would include rather than exclude (perhaps those are better names?) object:include(.b,.c) now. Are these good ideas to actually add to jsonselect? I have no idea. they're definitely level 3 additions if they should be added at all. thoughts? lloyd On Jun 3, 2011, at 7:43 AM, Dunk Fordyce wrote: > Hi, > > If you have for example: > > [ > {a: 1, b: 2, c: 3}, > {a: 4, b: 5, c: 6}, > {a: 7, b: 8, c: 9}, > ] > > Is it possible to jsonselect match it to: > > [ > {b: 2, c: 3}, > {b: 5, c: 6}, > {b: 8, c: 9}, > ] > > If its not possible ( I cant see how at the moment... ) could it be possible? > > I tried selecting ".b, .c" but I understand thats wrong ( and your not even garunteed to get "[.b, .c]" but possibly "[.c, .b]" ) > > Thanks! > Dunk
I think the possibility to do things like this would be very good and
it also works well with "YOU'RE SENDING LOTS OF DATA THAT PEOPLE DON'T
CARE ABOUT." :)
crazy idea: Iv been wondering about some totally non css style syntax
(that would probably be rejected...), something like:
"object {.b, .c}" # for each object create a new object selecting
.b and .c (keys would be "b" and "c")
"object {e: .b, f: .c}" # same but rename the keys
"object [.b, .c]" # for each object create and array of [.b, .c]
actually... maybe that could be shoved into a function:
obhect:new-obj(.b, .c)
object:new-obj(e: .b, c: .d)
object:new-array(.b, .c)
( i dont like the names new-obj/new-array very much but I cant think
of any better names atm )
On Fri, Jun 3, 2011 at 5:06 PM, Lloyd Hilaiel <lloyd@hilaiel.com> wrote:
>
> Hi!
>
> gosh, that's an interesting case. No, this is not possible in
jsonselect right now.
>
> Nowhere in jsonselect right now are values changed or filtered in any way.
>
> What you're really asking for here is that ability. One could imagine
the addition of two new functions: :filter() and :include() (names might
be wrong).
>
> The would work like this:
>
> :filter(S) - when applied to the last selector in a sequence, contains
a selector that will be applied against matching objects. any nested
values that match said selector will be removed.
>
> :root > object:filter(.a)
>
> or equivalently:
>
> object:filter(.a)
> or
> :root > :filter(.a)
>
> The :include() pf would be the opposite. so it would include rather
than exclude (perhaps those are better names?)
>
> object:include(.b,.c)
>
> now. Are these good ideas to actually add to jsonselect? I have no
idea. they're definitely level 3 additions if they should be added at
all.
>
> thoughts?
> lloyd
>
> On Jun 3, 2011, at 7:43 AM, Dunk Fordyce wrote:
>
> > Hi,
> >
> > If you have for example:
> >
> > [
> > {a: 1, b: 2, c: 3},
> > {a: 4, b: 5, c: 6},
> > {a: 7, b: 8, c: 9},
> > ]
> >
> > Is it possible to jsonselect match it to:
> >
> > [
> > {b: 2, c: 3},
> > {b: 5, c: 6},
> > {b: 8, c: 9},
> > ]
> >
> > If its not possible ( I cant see how at the moment... ) could it be possible?
> >
> > I tried selecting ".b, .c" but I understand thats wrong ( and your not
even garunteed to get "[.b, .c]" but possibly "[.c, .b]" )
> >
> > Thanks!
> > Dunk
>
On Jun 3, 2011, at 10:56 AM, Dunk Fordyce wrote: > I think the possibility to do things like this would be very good and > it also works well with "YOU'RE SENDING LOTS OF DATA THAT PEOPLE DON'T > CARE ABOUT." :) ok, you and ben are right. You can't do "YOU'RE SENDING LOTS OF DATA THAT PEOPLE DON'T CARE ABOUT." for relatively flat data representations without this feature. now back to the naming question... lloyd
On Jun 3, 2011, at 10:56 AM, Dunk Fordyce wrote: > crazy idea: Iv been wondering about some totally non css style syntax > (that would probably be rejected...), something like: > > "object {.b, .c}" # for each object create a new object selecting > .b and .c (keys would be "b" and "c") > "object {e: .b, f: .c}" # same but rename the keys > "object [.b, .c]" # for each object create and array of [.b, .c] zoiks. I'm hesitant to invent new syntax.... > actually... maybe that could be shoved into a function: > > obhect:new-obj(.b, .c) > object:new-obj(e: .b, c: .d) > object:new-array(.b, .c) ... especially when things fit so nicely into a function. Ok, so now you're looking to modify and generate structure from within functions. This is the part where I dig in my heels and ask what kind of compelling use cases you have in mind here? cause really I might have to rename the project from JSONSelect to JSONTransform! :P lloyd
On Fri, Jun 3, 2011 at 7:10 PM, Lloyd Hilaiel <lloyd@hilaiel.com> wrote: > Ok, so now you're looking to modify and generate structure from within functions. This is the part where I dig in my heels and ask what kind of compelling use cases you have in mind here? > > cause really I might have to rename the project from JSONSelect to JSONTransform! :P JSONSelect/XPath JSONTransform/XSLT :D Maybe your right and it should be a different thing... Would it be feasable ( and perform well ) to write some sort of transform lib on top of JSONSelect? Im thinking your already seeking thru the object so it should be doing a transform at the same time... { mynewobj: { type: 'newtype', val: {$sel: .some.json.selector} } }
On Jun 3, 2011, at 1:24 PM, Dunk Fordyce wrote: > On Fri, Jun 3, 2011 at 7:10 PM, Lloyd Hilaiel <lloyd@hilaiel.com> wrote: >> Ok, so now you're looking to modify and generate structure from within functions. This is the part where I dig in my heels and ask what kind of compelling use cases you have in mind here? >> >> cause really I might have to rename the project from JSONSelect to JSONTransform! :P > > JSONSelect/XPath JSONTransform/XSLT :D > > Maybe your right and it should be a different thing... > > Would it be feasable ( and perform well ) to write some sort of > transform lib on top of JSONSelect? Im thinking your already seeking > thru the object so it should be doing a transform at the same time... > > { > mynewobj: { > type: 'newtype', > val: {$sel: .some.json.selector} > } > } That's interesting. If the transformations you want to perform something that could be done after the selection phase, then they would integrate rather well. Have a look at the forEach method which invokes a callback as each match is found (.match itself is implemented using forEach): https://github.com/lloyd/JSONSelect/blob/master/src/jsonselect.js#L518-520 now to the parsing phase: how would a transformation layer affect the parser? Have a look at this error: https://github.com/lloyd/JSONSelect/blob/master/src/jsonselect.js#L39 thrown here: https://github.com/lloyd/JSONSelect/blob/master/src/jsonselect.js#L93 What if before throwing an error we called up to higher level code and said : "Yo, here's a pseudo thingy I don't understand. do you understand it?" food for thought. One thing that confuses me though is what the specific syntax would be for these transformations. unlike the other pseudo functions, they would be per *selector* and not allowed in *simple_selector_sequnces* (using production names from grammar: https://github.com/lloyd/JSONSelect/blob/master/JSONSelect.md) interestingly, this same issue applies for :include() and :exclude()... lloyd
https://github.com/kriszyp/rql supports this case, with its select operator. The query syntax is simply "select(b,c)". Here's an example of performing the query with node.js: https://gist.github.com/1006625 I think select() is a good choice of a word. To me, filter() sounds like it would exclude items in the array, not items from each of the results. If it doesn't make sense to add this to jsonselect, rql might be the right tool for this particular job. Ben Atkin On Fri, Jun 3, 2011 at 7:43 AM, Dunk Fordyce <dunkfordyce@gmail.com> wrote: > Hi, > > If you have for example: > > [ > {a: 1, b: 2, c: 3}, > {a: 4, b: 5, c: 6}, > {a: 7, b: 8, c: 9}, > ] > > Is it possible to jsonselect match it to: > > [ > {b: 2, c: 3}, > {b: 5, c: 6}, > {b: 8, c: 9}, > ] > > If its not possible ( I cant see how at the moment... ) could it be > possible? > > I tried selecting ".b, .c" but I understand thats wrong ( and your not even > garunteed to get "[.b, .c]" but possibly "[.c, .b]" ) > > Thanks! > Dunk >
On Jun 3, 2011, at 10:25 AM, Ben Atkin wrote:
> I think select() is a good choice of a word. To me, filter() sounds like
it would exclude items in the array, not items from each of the results.
select() seems too meta/recursive/overloaded to me. given that it's a
pseudo function inside a selector written in JSONSelect. aaaah.
include() and exclude() ?
only() and without() ?
gimme() and keep() ?
yeah. kidding.
lloyd
On Fri, Jun 3, 2011 at 11:05 AM, Lloyd Hilaiel <lloyd@hilaiel.com> wrote: > On Jun 3, 2011, at 10:25 AM, Ben Atkin wrote: > > > I think select() is a good choice of a word. To me, filter() sounds like > it would exclude items in the array, not items from each of the results. > > select() seems too meta/recursive/overloaded to me. given that it's a > pseudo function inside a selector written in JSONSelect. aaaah. > Good point. I agree. > include() and exclude() ? > This is pretty good. Rubyists might confuse it with include? only() and without() ? > This is my favorite. Though I'm not that confident in my choice. > gimme() and keep() ? > Haha. Server, you can keep those keys...I don't need them. yeah. kidding. > > lloyd > > > Whatever the name, will it be natural to be able to ask for just a nested key? For example, would something like this: object:only(.a .b) ...just return [{"a":"b":1}] on the following array? [ { "a": {"b": 1}, "b": 2 } ]
On Jun 3, 2011, at 11:22 AM, Ben Atkin wrote: > > > On Fri, Jun 3, 2011 at 11:05 AM, Lloyd Hilaiel <lloyd@hilaiel.com> wrote: > On Jun 3, 2011, at 10:25 AM, Ben Atkin wrote: > > > I think select() is a good choice of a word. To me, filter() sounds like it would exclude items in the array, not items from each of the results. > > select() seems too meta/recursive/overloaded to me. given that it's a pseudo function inside a selector written in JSONSelect. aaaah. > > Good point. I agree. > > include() and exclude() ? > > This is pretty good. Rubyists might confuse it with include? > > only() and without() ? > > This is my favorite. Though I'm not that confident in my choice. > > gimme() and keep() ? > > Haha. Server, you can keep those keys...I don't need them. > > yeah. kidding. > > lloyd ok, moving this into github issues to record it... > Whatever the name, will it be natural to be able to ask for just a nested key? For example, would something like this: > > object:only(.a .b) > > ...just return [{"a":"b":1}] on the following array? > > [ > { > "a": {"b": 1}, > "b": 2 > } > ] yes. I'm thinking like :has(), we'd accept a full selector. then that selector would be applied to the result which would trim it down. so your example would return two results: 1. { "a": {"b": 1} } 2. { } the second result would be matching :only(.a .b) against {"b":1} seem reasonable? lloyd
I think that would make sense if the data was this:
[
{
"a": {"b": 1}
},
{
"b": 2
}
]
...but with the data being the way I had it in my last reply I think it
would make sense for it to return just one object because there was just one
array element.
On Fri, Jun 3, 2011 at 11:38 AM, Lloyd Hilaiel <lloyd@hilaiel.com> wrote:
>
> On Jun 3, 2011, at 11:22 AM, Ben Atkin wrote:
> >
> >
> > On Fri, Jun 3, 2011 at 11:05 AM, Lloyd Hilaiel <lloyd@hilaiel.com>
> wrote:
> > On Jun 3, 2011, at 10:25 AM, Ben Atkin wrote:
> >
> > > I think select() is a good choice of a word. To me, filter() sounds
> like it would exclude items in the array, not items from each of the
> results.
> >
> > select() seems too meta/recursive/overloaded to me. given that it's a
> pseudo function inside a selector written in JSONSelect. aaaah.
> >
> > Good point. I agree.
> >
> > include() and exclude() ?
> >
> > This is pretty good. Rubyists might confuse it with include?
> >
> > only() and without() ?
> >
> > This is my favorite. Though I'm not that confident in my choice.
> >
> > gimme() and keep() ?
> >
> > Haha. Server, you can keep those keys...I don't need them.
> >
> > yeah. kidding.
> >
> > lloyd
>
> ok, moving this into github issues to record it...
>
> > Whatever the name, will it be natural to be able to ask for just a nested
> key? For example, would something like this:
> >
> > object:only(.a .b)
> >
> > ...just return [{"a":"b":1}] on the following array?
> >
> > [
> > {
> > "a": {"b": 1},
> > "b": 2
> > }
> > ]
>
> yes. I'm thinking like :has(), we'd accept a full selector. then that
> selector would be applied to the result which would trim it down. so your
> example would return two results:
>
> 1. { "a": {"b": 1} }
> 2. { }
>
> the second result would be matching :only(.a .b) against {"b":1}
>
> seem reasonable?
>
> lloyd
>
On Jun 3, 2011, at 11:56 AM, Ben Atkin wrote: > I think that would make sense if the data was this: > > [ > { > "a": {"b": 1} > }, > { > "b": 2 > } > ] > > ...but with the data being the way I had it in my last reply I think it would make sense for it to return just one object because there was just one array element. hmmm. I don't think I understand the semantics you are looking for. Specifically I don't why :only() cares about arrays. How I'm looking at it is that :only() is a filter that applies to elements that are selected by the selector to which it is attached, but has absolutely no affect on which elements will be matched. ? lloyd
I see. I wasn't thinking of the algorithm properly. In fact I was mixing it up a bit with rql. On Fri, Jun 3, 2011 at 12:24 PM, Lloyd Hilaiel <lloyd@hilaiel.com> wrote: > On Jun 3, 2011, at 11:56 AM, Ben Atkin wrote: > > > I think that would make sense if the data was this: > > > > [ > > { > > "a": {"b": 1} > > }, > > { > > "b": 2 > > } > > ] > > > > ...but with the data being the way I had it in my last reply I think it > would make sense for it to return just one object because there was just one > array element. > > hmmm. I don't think I understand the semantics you are looking for. > Specifically I don't why :only() cares about arrays. > > How I'm looking at it is that :only() is a filter that applies to elements > that are selected by the selector to which it is attached, but has > absolutely no affect on which elements will be matched. > > ? > > lloyd >
https://github.com/lloyd/JSONSelect/issues/18 On Jun 3, 2011, at 12:33 PM, Ben Atkin wrote: > I see. I wasn't thinking of the algorithm properly. In fact I was mixing it up a bit with rql. > > On Fri, Jun 3, 2011 at 12:24 PM, Lloyd Hilaiel <lloyd@hilaiel.com> wrote: > On Jun 3, 2011, at 11:56 AM, Ben Atkin wrote: > > > I think that would make sense if the data was this: > > > > [ > > { > > "a": {"b": 1} > > }, > > { > > "b": 2 > > } > > ] > > > > ...but with the data being the way I had it in my last reply I think it would make sense for it to return just one object because there was just one array element. > > hmmm. I don't think I understand the semantics you are looking for. Specifically I don't why :only() cares about arrays. > > How I'm looking at it is that :only() is a filter that applies to elements that are selected by the selector to which it is attached, but has absolutely no affect on which elements will be matched. > > ? > > lloyd >