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

[Stephanie M. Gogarten]

Rather than a class union, how about an internal function that is called 
by the methods for both matrix and DelayedArray:


setGeneric("myNewRowMeans", function(x,...) { 
standardGeneric("myNewRowMeans")})

#' @importFrom DelayedArray rowMeans
.myNewRowMeans <- 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)
}

setMethod("myNewRowMeans",
           signature = "matrix",
           definition = function(x,...){
               .myNewRowMeans(x,...)
           }
)

setMethod("myNewRowMeans",
           signature = "DelayedArray",
           definition = function(x,...){
               .myNewRowMeans(x,...)
           }
)


On 4/30/18 9:10 AM, Tim Triche, Jr. 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
>