Tim: As the developer of DelayedMatrixStats (and enthusiastic 'canary down the coal mine' user-dev of DelayedArray) I'm obviously invested in reducing the confusion around these packages
I'm going to write some blog posts-cum-vignettes-cum-F1000 around these issues over the coming weeks, with the ultimate goal of improving the packages themselves. Pete On Mon., 30 Apr. 2018, 12:11 pm Tim Triche, Jr., <tim.tri...@gmail.com> wrote: > But if you merge methods like that, the error method can be that much more > difficult to identify. It took a couple of weeks to chase that bug down > properly, and it ended up down to rowMeans2 vs rowMeans. > > I suppose the merged/abstracted method allows to centralize any such > dispatch into one place and swap out ill-behaved methods once identified, > so as long as DelayedArray/DelayedMatrixStats quirks are > documented/understood, maybe it is better to create this union class? > > The Matrix/matrixStats/DelayedMatrix/DelayedMatrixStats situation has been > "interesting" in practical terms, as seemingly simple abstractions appear > to require more thought. That was my only point. > > > --t > > On Mon, Apr 30, 2018 at 11:28 AM, Martin Morgan < > martin.mor...@roswellpark.org> wrote: > > > But that issue will be fixed, so Tim's advice is inappropriate. > > > > > > On 04/30/2018 10:42 AM, Tim Triche, Jr. wrote: > > > >> Don't do that. Seriously, just don't. > >> > >> https://github.com/Bioconductor/DelayedArray/issues/16 > >> > >> --t > >> > >> On Mon, Apr 30, 2018 at 10:02 AM, Elizabeth Purdom < > >> epur...@stat.berkeley.edu> wrote: > >> > >> Hello, > >>> > >>> I am trying to extend my package to handle `HDF5Matrix` class ( or more > >>> generally `DelayedArray`). I currently have S4 functions for `matrix` > >>> class. Usually I have a method for `SummarizedExperiment`, which will > >>> call > >>> call the method on `assay(x)` and I want the method to be able to deal > >>> with > >>> if `assay(x)` is a `DelayedArray`. > >>> > >>> Most of my functions, however, do not require separate code depending > on > >>> whether `x` is a `matrix` or `DelayedArray`. They are making use of > >>> existing functions that will make that choice for me, e.g. rowMeans or > >>> subsetting. My goal right now is compatibility, not cleverness, and I'm > >>> not > >>> creating HDF5 methods to handle other cases. (If something doesn't > >>> currently exist, then I just enclose `x` with `data.matrix` or > >>> `as.matrix` > >>> and call the matrix into memory — for cleanliness and ease in updating > >>> with > >>> appropriate methods in future, I could make separate S4 functions for > >>> these > >>> specific tasks to dispatch, but that's outside of the scope of my > >>> question). So for simplicity assume I don't really need to dispatch *my > >>> code* -- that the methods I'm going to use do that. > >>> > >>> The natural solution for me seem to use `setClassUnion` and I was > >>> wondering if such a virtual class already exists? Or is there a better > >>> way > >>> to handle this? > >>> > >>> Here's a simple example, using `rowMeans` as my example: > >>> > >>> ``` > >>> setGeneric("myNewRowMeans", function(x,...) { standardGeneric(" > >>> myNewRowMeans")}) > >>> setClassUnion("matrixOrDelayed",members=c("matrix", "DelayedArray")) > >>> > >>> #' @importFrom DelayedArray rowMeans > >>> setMethod("myNewRowMeans", > >>> signature = "matrixOrDelayed", > >>> definition = function(x,...){ > >>> # a lot of code independent of x > >>> print("This is a lot of code shared regardless > >>> of > >>> class of x\n") > >>> # a lot of code that depends on x, but is > >>> dispatched by the functions called > >>> out<-rowMeans(x) > >>> #a lot of code based on output of out > >>> out<-out+1 > >>> return(out) > >>> } > >>> ) > >>> ``` > >>> > >>> _______________________________________________ > >>> Bioc-devel@r-project.org mailing list > >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel > >>> > >>> > >> [[alternative HTML version deleted]] > >> > >> _______________________________________________ > >> Bioc-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/bioc-devel > >> > >> > > > > This email message may contain legally privileged and/or confidential > > information. If you are not the intended recipient(s), or the employee > or > > agent responsible for the delivery of this message to the intended > > recipient(s), you are hereby notified that any disclosure, copying, > > distribution, or use of this email message is prohibited. If you have > > received this message in error, please notify the sender immediately by > > e-mail and delete this email message from your computer. Thank you. > > > > [[alternative HTML version deleted]] > > _______________________________________________ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
