[Bioc-devel] Virtual class for `matrix` and `DelayedArray`? (or better strategy for dealing with them both)

[Peter Hickey]

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.triche at 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.morgan at 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 <
> >> epurdom at 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 at r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >>>
> >>>
> >>         [[alternative HTML version deleted]]
> >>
> >> _______________________________________________
> >> Bioc-devel at 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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

	[[alternative HTML version deleted]]