Re: [Bioc-devel] Why should Bioconductor developers re-use core classes?

Thanks for those additional comments, Levi. I don't think you were being unfair to phyloseq, and it sounds like some of the issues involved are still relevant (e.g. new domain, new contributor). I wanted to riff on Martin's comment about "incremental gain rather than perfection". I imagine there

Re: [Bioc-devel] Why should Bioconductor developers re-use core classes?

On Thu, Oct 19, 2017 at 10:12 AM, Levi Waldron wrote: > Thanks for all your thoughts Joey, and I hope I didn't come across as > ... > > On Wed, Oct 18, 2017 at 11:36 PM, Paul Joseph McMurdie > wrote: > > ... > > > - There actually *still isn't

Re: [Bioc-devel] Why should Bioconductor developers re-use core classes?

Thanks for all your thoughts Joey, and I hope I didn't come across as critical of phyloseq in particular. In fact, the couple packages I created as a post-doc (doppelgangR and ffpe) did exactly the same thing, but unlike phyloseq have never been used enough for it to make much difference :). This

Re: [Bioc-devel] Why should Bioconductor developers re-use core classes?

Thanks, Levi, nice slides. In case it is a helpful perspective, I'll try to share what I recall of my thought process as author of phyloseq. And I should preface by admitting that I've been embarrassed by this major development oversight for some years now. At the beginning of 2011 I was a new

Re: [Bioc-devel] Why should Bioconductor developers re-use core classes?

I just converted my gene set data structures to GSEABase::GenSet class. I think that one major advantage is that I just transferred the burden of staying up to date with gene set formats to people working specifically on that. If the file formats from the MSigDB change, someone will work on

Re: [Bioc-devel] Why should Bioconductor developers re-use core classes?

Good day, It might be useful to readers to have a comparison table (ticks and crosses) in the MultiAssayExperiment vignette that compares the features available in it to those available in SummarizedExperiment, to allow quicker decision making. -- Dario

Re: [Bioc-devel] Why should Bioconductor developers re-use core classes?

> > On Wed, Oct 18, 2017 at 10:26 AM, Ryan Thompson > wrote: > >> I think the main reason for reusing/subclassing core classes that users >> can >> appreciate is that it makes it much easier for users to integrate multiple >> packages into a single workflow. Only the most

Re: [Bioc-devel] Why should Bioconductor developers re-use core classes?

Good points. I think Levi hit on the direct reuse argument (via inheritance and composition), and, you're right, interoperability is another big one. On Wed, Oct 18, 2017 at 10:26 AM, Ryan Thompson wrote: > I think the main reason for reusing/subclassing core classes that

Re: [Bioc-devel] Why should Bioconductor developers re-use core classes?

I think the main reason for reusing/subclassing core classes that users can appreciate is that it makes it much easier for users to integrate multiple packages into a single workflow. Only the most basic of pipelines uses just a single Bioconductor package. For instance, an "edgeR" pipeline

Re: [Bioc-devel] Why should Bioconductor developers re-use core classes?

It should also be pointed out that reference classes classes are rarely needed and can easily be used for the wrong reasons (e.g. performance?). The pass-by-reference semantic they provide can fire back. Most of the time objects don't need and should not have pass-by-reference semantic, only

Re: [Bioc-devel] Why should Bioconductor developers re-use core classes?

If Biocondutor integration is important, then reference classes (setRefClass) are preferable, since they fully integrate with the rest of S4, including class hierarchies and method dispatch. It's important not to be confused by the R6 branding. It's (sort of) an alternative to S4, not an evolution

Re: [Bioc-devel] Why should Bioconductor developers re-use core classes?

Good day, I developed ClassifyR, which is a classification framework, based on ExpressionSet. Now that we're getting enquiries about inputting multiple datasets derived from the same patients, we plan to completely refactor the software to use MultiAssayExperiment as a foundation class.