I want to raise a question about this from the perspective of intersystems
interfacing. You can use reticulate to import your python into R, once you
have installed the python library for biothings_client
library(reticulate)
bt = import("biothings_client")
mv = bt$get_client("variant")
myv = mv$getvariant("chr7:g.140453134T>C")
it works fine. do you really want to maintain R code that only reflects
what is already coded in python?
we still need to think about the user interface and the annotation objects
that come back, but i wonder whether effort and code could be conserved by
letting python do what it already does, and using R to to what python does
not (at this point).
On Fri, Oct 20, 2017 at 12:14 PM, Herv? Pag?s <hpages at fredhutch.org>
wrote:
Hi,
On 10/19/2017 05:50 PM, Ryan Thompson wrote:
Hi Chunlei,
One thing you could do to make the interface more traditional is to
global "query" function that takes a client object as an additional
argument.
Usage would be something like:
gene_client <- BioThingsClient("gene")
query("CDK2", client=gene_client)
To simplify this for common use cases, you could also have query accept
another argument named "type", which is just a string that is passed to
BioThingsClient to construct a new client on the spot:
query("CDK2", type="gene")
Note that the same 'type' argument could accept a GeneClient object or
a single string. There is no need for 2 separate arguments.
Also I guess you'll want to support passing a *vector* of gene symbols
or gene ids. Vectorization in R is a big deal and has important
consequences on how one designs an API in R versus in other languages.
Cheers,
H.
And thus the user never needs to interact directly with the client class
unless they need to set some other options besides the query type.
Obviously it should thrown an error if both client and type are passed.
Additionally, for interactive use, it might be useful to define an
to set the default client to use if none is passed, e.g.
options(default.biothings.client = BioThingsClient("gene"))
query("CDK2")
Lastly, if you go this route, you will probably want to pick a more
specific name for the query function, this design makes it globally
visible
rather attached to an object. More generally, all the function/argument
names I've provided are just example names.
Anyway, I'm not very experienced designing object-oriented interfaces in
R,
but that's my 2 cents from a user perspective of how I would expect such
an
R package to work. Hopefully others with more class design experience
provide additional advice.
-Ryan
On Thu, Oct 19, 2017 at 5:25 PM Chunlei Wu <cwu at scripps.edu> wrote:
Hello BioC-dev group,
We are working on a new R package right now and plan to
submit
it to Bioconductor soon. It's a unified R client for the collection of
BioThings APIs (https://urldefense.proofpoint.com/v2/url?u=http-3A__
biothings.io&d=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvim
eWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=YcUQDz1TBC75vTHUjJF-PzFyL
cGFiB9CuKxo85Fn7AQ&s=XC1oz8ByA8ZqKK3-FImqVgqMQHms9a1SJ3rGP7l9h0Y&e=).
Using R6 class, it makes a lot
sense to me as I'm coming from Python's OOP experience. It will be used
like this:
library(biothings)
gene_client <- BioThingsR6$new("gene")
gene_client$query("CDK2")
variant_client <- BioThingsR6$new("variant")
gene_client$query("dbsnp.rsid:rs1000")
Each "client" above is corresponding to a specific BioThings API, e.g.
one
for gene, and one for variant. And we will have more "clients" as we
expanding the number of BioThings API. The same R code should work with
the
future APIs.
But if we use the traditional S4 class, it will be awkward as all
functions/methods are not "namespaced", we will need to define new
functions for each additional API. Something like this:
library(biothings)
geneQuery("CDK2")
variantQuery("dbsnp.rsid:rs1000")
I also want to mention that "query" is not the only method for each API
client, there will be several other methods for each client. It will
quickly make the function names messy if we go with the S4 option.
Anyway, we think we like R6 class better, but just want to get some
feedback here if the usage pattern using R6 class has been
in
the R community. Will the users feel cumbersome if they have to
instantiate
the class first and then make the function calls? The majority of the
existing BioC package are indeed S4 class based, which makes us feel
hesitated.
Thanks,
Chunlei
[[alternative HTML version deleted]]