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

Tim Triche, Jr. tim.triche at gmail.com
Mon Apr 30 18:10:19 CEST 2018


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]]



More information about the Bioc-devel mailing list