[Bioc-devel] R6 class v.s. S4 class

Fri Oct 20 18:40:36 CEST 2017

As long as the logic has been pushed down into the server, the R interface
should be lightweight, and there's no need to introduce a dependency on
python.

On Fri, Oct 20, 2017 at 9:27 AM, Vincent Carey <stvjc at channing.harvard.edu>
wrote:

> 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
> 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 <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
> 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 at 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 at 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: hpages at fredhutch.org
> > Phone:  (206) 667-5791
> > Fax:    (206) 667-1319
> >
> >
> > _______________________________________________
> > Bioc-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
>         [[alternative HTML version deleted]]
>
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

	[[alternative HTML version deleted]]