[Bioc-devel] R6 class v.s. S4 class
stvjc at channing.harvard.edu
Fri Oct 20 18:27:09 CEST 2017
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
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:
> 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
>> 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.
>> 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"))
>> 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
>> 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
>> but that's my 2 cents from a user perspective of how I would expect such
>> R package to work. Hopefully others with more class design experience can
>> provide additional advice.
>> 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
>>> 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__
>>> 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:
>>> gene_client <- BioThingsR6$new("gene")
>>> variant_client <- BioThingsR6$new("variant")
>>> Each "client" above is corresponding to a specific BioThings API, e.g.
>>> 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
>>> 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:
>>> 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
>>> the R community. Will the users feel cumbersome if they have to
>>> 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
>>> [[alternative HTML version deleted]]
>>> Bioc-devel at r-project.org mailing list
>> [[alternative HTML version deleted]]
>> Bioc-devel at r-project.org mailing list
> 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: hpages at fredhutch.org
> Phone: (206) 667-5791
> Fax: (206) 667-1319
> Bioc-devel at r-project.org mailing list
[[alternative HTML version deleted]]
More information about the Bioc-devel