[Bioc-devel] Pushing towards a better home for matrix generics
Pages, Herve
hp@ge@ @end|ng |rom |redhutch@org
Mon Apr 15 06:56:06 CEST 2019
I installed R 3.6 beta and can confirm that the clashes between the row/colSums and row/colMeans generics from Matrix and BiocGenerics are gone. Excellent! Thanks Michael.
H.
On 4/9/19 11:15, Michael Lawrence wrote:
This should be in trunk and the 3.6 release branch.
On Thu, Mar 28, 2019 at 9:57 AM Michael Lawrence <michafla using gene.com<mailto:michafla using gene.com>> wrote:
Not yet. Too busy breaking other things ;) I'll move it up on my TODO list.
On Thu, Mar 28, 2019 at 9:16 AM Pages, Herve <hpages using fredhutch.org<mailto:hpages using fredhutch.org>> wrote:
Hi Michael,
Did you get a chance to make this change?
Thanks,
H.
On 2/11/19 08:07, Michael Lawrence wrote:
> I propose that we just fix the signatures in the methods package and
> deal with the consequences. If Martin's OK with that, I'll make the
> change.
>
> Michael
>
> On Mon, Feb 11, 2019 at 7:45 AM McDavid, Andrew
> <Andrew_Mcdavid using urmc.rochester.edu<mailto:Andrew_Mcdavid using urmc.rochester.edu>> wrote:
>> As a casual observer of this thread, my takeaway is that 1. the current situation is untenable (e.g. it means that Aaron would have to essentially reimplement S4 method dispatch) 2. Given the long history, and extent of reverse dependencies to Matrix, there are good reasons to not mess with the signature of its implicit generic (though I don't see much utility in multiple dispatch here) and 3. therefore the least-bad alternative may be to eliminate the call to setGeneric('colSums'), etc, in BiocGenerics, hopefully with some fixes to the help system to make it more tolerant to S4 method naming. I appreciate that until these fixes are forthcoming it means more work maintaining the help aliases for some methods. How often do we think the aliases would be break?
>>
>> Andrew McDavid
>> Biostatistics and Computational Biology
>> Office: SRB 4.206 Ph: 585.275.5983
>>
>> Message: 1
>> Date: Sun, 10 Feb 2019 13:36:43 +0000
>> From: Aaron Lun <infinite.monkeys.with.keyboards using gmail.com<mailto:infinite.monkeys.with.keyboards using gmail.com><mailto:infinite.monkeys.with.keyboards using gmail.com<mailto:infinite.monkeys.with.keyboards using gmail.com>>>
>> To: "Pages, Herve" <hpages using fredhutch.org<mailto:hpages using fredhutch.org><mailto:hpages using fredhutch.org<mailto:hpages using fredhutch.org>>>, Martin Maechler
>> <maechler using stat.math.ethz.ch<mailto:maechler using stat.math.ethz.ch><mailto:maechler using stat.math.ethz.ch<mailto:maechler using stat.math.ethz.ch>>>
>> Cc: Michael Lawrence <lawrence.michael using gene.com<mailto:lawrence.michael using gene.com><mailto:lawrence.michael using gene.com<mailto:lawrence.michael using gene.com>>>,
>> "bioc-devel using r-project.org<mailto:bioc-devel using r-project.org><mailto:bioc-devel using r-project.org<mailto:bioc-devel using r-project.org>>" <bioc-devel using r-project.org<mailto:bioc-devel using r-project.org><mailto:bioc-devel using r-project.org<mailto:bioc-devel using r-project.org>>>
>> Subject: Re: [Bioc-devel] Pushing towards a better home for matrix
>> generics
>> Message-ID: <1549805803.3935.11.camel using gmail.com<mailto:1549805803.3935.11.camel using gmail.com><mailto:1549805803.3935.11.camel using gmail.com<mailto:1549805803.3935.11.camel using gmail.com>>>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Returning to this topic:
>>
>> It's good to hear some of the rationale behind the current state of
>> affairs. That said, the set-up we have now is quite difficult to work
>> with; as mentioned before, I've had to hack around it like:
>>
>> # Example from "BiocSingular", https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_LTLA_BiocSingular&d=DwIGaQ&c=4sF48jRmVAe_CH-k9mXYXEGfSnM3bY53YSKuLUQRxhA&r=YOujD4cGNGWN0ZskTj96dUHU2a4CkraklBd4BndS21sf3_emyYLIG1llnUarWCda&m=VBZgu2tHS9vBNQ2d8RSG4ijIcp3jyZkfCsRnA1mk7XI&s=FN4WdWx8gfnjFoLRQuBaIHaKrAjONVa9hsbAyIXSwGo&e=
>> .safe_colSums <- function(x) {
>> if (is(x, "Matrix")) {
>> Matrix::colSums(x)
>> } else {
>> colSums(x)
>> }
>> }
>>
>> ... which is ugly, and even worse, still incorrect, e.g., for non-
>> Matrix classes that have methods for the implicit colSums generic. This
>> situation is not sustainable for further package development.
>>
>> Is there a path forward that is palatable to everyone? Or perhaps these
>> conversations are already happening on R-devel?
>>
>> -A
>>
>> On Tue, 2019-01-29 at 18:46 +0000, Pages, Herve wrote:
>> Yes the help system could enforce the full signature for the aliases
>> but
>> that means the end user then will have to always do
>> ?`colSums,SomeClass,ANY,ANY-method`, which feels unnecessary
>> complicated
>> and confusing in the case of a generic where dispatching on the 2nd
>> and
>> 3rd arguments hardly makes sense.
>>
>> Or are you saying that the help system should enforce an alias that
>> strictly matches the signature explicitly used in the setMethod
>> statement? Problem with this is that then there is no easy way for
>> the
>> end user to know a priori which form to use to access the man page.
>> Is
>> it ?`colSums,dgCMatrix,ANY,ANY-method` or is it
>> ?`colSums,dgCMatrix-method`. Right now when you type colSums<ENTERN>
>> (after loading the Matrix package), you get this:
>>
>> > library(Matrix)
>> > colSums
>> standardGeneric for "colSums" defined from package "base"
>>
>> function (x, na.rm = FALSE, dims = 1, ...)
>> standardGeneric("colSums")
>> <bytecode:0x591c7d0>
>> <environment:0x591a408>
>> Methods may be defined for arguments: x, na.rm, dims
>> Use showMethods("colSums") for currently available ones.
>>
>> This suggests that the correct form is ?`colSums,dgCMatrix,ANY,ANY-
>> method`.
>>
>> All this confusion can be avoided by specifying signature="x" in the
>> definition of the implicit generic. It formalizes where dispatch
>> really
>> happens and sets expectations upfront. No loose ends.
>>
>> Hope this makes sense,
>>
>> H.
>>
>>
>> [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> Bioc-devel using r-project.org<mailto:Bioc-devel using r-project.org> mailing list
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=k36We8maIPURbmBswkPb0UI6ovVg-QOOSA30a92R1-g&s=L4de4KlbgiqHQj6_DCIPzOtVY0uE8DJZJhwvOHHQAvM&e=
> _______________________________________________
> Bioc-devel using r-project.org<mailto:Bioc-devel using r-project.org> mailing list
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=k36We8maIPURbmBswkPb0UI6ovVg-QOOSA30a92R1-g&s=L4de4KlbgiqHQj6_DCIPzOtVY0uE8DJZJhwvOHHQAvM&e=
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpages using fredhutch.org<mailto:hpages using fredhutch.org>
Phone: (206) 667-5791
Fax: (206) 667-1319
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpages using fredhutch.org<mailto:hpages using fredhutch.org>
Phone: (206) 667-5791
Fax: (206) 667-1319
[[alternative HTML version deleted]]
More information about the Bioc-devel
mailing list