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 <micha...@gene.com<mailto:micha...@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 <hpa...@fredhutch.org<mailto:hpa...@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_mcda...@urmc.rochester.edu<mailto:andrew_mcda...@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.keyboa...@gmail.com<mailto:infinite.monkeys.with.keyboa...@gmail.com><mailto:infinite.monkeys.with.keyboa...@gmail.com<mailto:infinite.monkeys.with.keyboa...@gmail.com>>> >> To: "Pages, Herve" >> <hpa...@fredhutch.org<mailto:hpa...@fredhutch.org><mailto:hpa...@fredhutch.org<mailto:hpa...@fredhutch.org>>>, >> Martin Maechler >> <maech...@stat.math.ethz.ch<mailto:maech...@stat.math.ethz.ch><mailto:maech...@stat.math.ethz.ch<mailto:maech...@stat.math.ethz.ch>>> >> Cc: Michael Lawrence >> <lawrence.mich...@gene.com<mailto:lawrence.mich...@gene.com><mailto:lawrence.mich...@gene.com<mailto:lawrence.mich...@gene.com>>>, >> "bioc-devel@r-project.org<mailto:bioc-devel@r-project.org><mailto:bioc-devel@r-project.org<mailto:bioc-devel@r-project.org>>" >> >> <bioc-devel@r-project.org<mailto:bioc-devel@r-project.org><mailto:bioc-devel@r-project.org<mailto:bioc-devel@r-project.org>>> >> Subject: Re: [Bioc-devel] Pushing towards a better home for matrix >> generics >> Message-ID: >> <1549805803.3935.11.ca...@gmail.com<mailto:1549805803.3935.11.ca...@gmail.com><mailto:1549805803.3935.11.ca...@gmail.com<mailto:1549805803.3935.11.ca...@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@r-project.org<mailto:Bioc-devel@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@r-project.org<mailto:Bioc-devel@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: hpa...@fredhutch.org<mailto:hpa...@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: hpa...@fredhutch.org<mailto:hpa...@fredhutch.org> Phone: (206) 667-5791 Fax: (206) 667-1319 [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
