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

[Hervé Pagès]

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=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=YcUQDz1TBC75vTHUjJF-PzFyLcGFiB9CuKxo85Fn7AQ&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.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=YcUQDz1TBC75vTHUjJF-PzFyLcGFiB9CuKxo85Fn7AQ&s=zACRgsjhIPMZ7QLKdJV4pdw84v1O_SCLyGGRFrJsBfY&e=
>>
>
> 	[[alternative HTML version deleted]]
>
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=YcUQDz1TBC75vTHUjJF-PzFyLcGFiB9CuKxo85Fn7AQ&s=zACRgsjhIPMZ7QLKdJV4pdw84v1O_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