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
