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 <hpa...@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 have a
>> 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 option
>> 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 can
>> provide additional advice.
>>
>> -Ryan
>>
>> On Thu, Oct 19, 2017 at 5:25 PM Chunlei Wu <c...@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 are
>>> 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 well-accepted
>>> 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]]
>>>
>>> _______________________________________________
>>> Bioc-devel@r-project.org mailing list
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.et
>>> hz.ch_mailman_listinfo_bioc-2Ddevel&d=DwICAg&c=eRAMFD45gAfqt
>>> 84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=Yc
>>> UQDz1TBC75vTHUjJF-PzFyLcGFiB9CuKxo85Fn7AQ&s=zACRgsjhIPMZ7QLK
>>> dJV4pdw84v1O_SCLyGGRFrJsBfY&e=
>>>
>>>
>> [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> Bioc-devel@r-project.org mailing list
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.et
>> hz.ch_mailman_listinfo_bioc-2Ddevel&d=DwICAg&c=eRAMFD45gAfqt
>> 84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=Yc
>> UQDz1TBC75vTHUjJF-PzFyLcGFiB9CuKxo85Fn7AQ&s=zACRgsjhIPMZ7QLK
>> dJV4pdw84v1O_SCLyGGRFrJsBfY&e=
>>
>>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpa...@fredhutch.org
> Phone: (206) 667-5791
> Fax: (206) 667-1319
>
>
> _______________________________________________
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
[[alternative HTML version deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
