Closed seandavi closed 8 years ago
This looks like a good start. I usually approach this problem by defining promise types. That allows much more flexibility, such as writing a custom filter function that is defined in terms of the primitive operators.
Can I bother you to point me to an example? On Jul 11, 2016 08:58, "Michael Lawrence" notifications@github.com wrote:
This looks like a good start. I usually approach this problem by defining promise types. That allows much more flexibility, such as writing a custom filter function that is defined in terms of the primitive operators.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Bioconductor/GenomicDataCommons/pull/7#issuecomment-231726663, or mute the thread https://github.com/notifications/unsubscribe/AAFpEylWBY5AO-mSfVo7Ow16Ta2RFlXZks5qUj3wgaJpZM4JI88a .
I guess you could look at https://github.com/lawremi/rsolr/blob/master/R/SolrPromise-class.R. But it's a bit complex. This case is much simpler. The basic idea is to evaluate the expression in an environment where there is a promise object for all symbols in the expression (i.e., all.vars(expr)
). Then define a method on "Logic" for that promise class that returns a promise representing the call. You probably only need a single promise class but it would hold either a symbol string or a list (JSON) as its compiled expression.
The SolrPromise stuff is VERY impressive. I'll spend some time on that one, as it seems like the Pro version of what I wanted to do. I can see this approach being useful in all kinds of API work.
Is there an (promise :) of an) updated patch to replace the current version? Not wanting to loose sight of the trees for the forest...
I am traveling for the next 2.5 weeks, so promise is perhaps a bit strong in both senses of the word. If anyone wants to either move forward with my juvenile approach or wants to go with the adult version instead, I won’t take it personally. That said, I do plan to work on this some when I can.
On Jul 11, 2016, at 5:09 PM, Martin Morgan notifications@github.com wrote:
Is there an (promise :) of an) updated patch to replace the current version? Not wanting to loose sight of the trees for the forest...
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Bioconductor/GenomicDataCommons/pull/7#issuecomment-231865992, or mute the thread https://github.com/notifications/unsubscribe/AAFpE6dZVsWirlLrYgqNLWDXZhmzFUNAks5qUrEegaJpZM4JI88a.
Closing this one and replacing with new pull request.
This certainly isn't clean, but this is my first foray into using R symbol tree parsing. Very cool stuff. Needs a lot of checking, etc., but as it stands, an end-user can use "quoted" R syntax to generate json that corresponds to available filters on a generic GDC endpoint.
I suspect this will need some further work, so feel free to ignore this alpha-level code if you like and wait for me to clean it up.