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=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@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@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: 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
