[Bioc-devel] Pushing towards a better home for matrix generics

Michael Lawrence |@wrence@m|ch@e| @end|ng |rom gene@com
Tue Apr 9 20:15:06 CEST 2019


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> 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> 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> 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>>
>> >> To: "Pages, Herve" <hpages using fredhutch.org<mailto:hpages using fredhutch.org>>,
>> Martin Maechler
>> >> <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>>,
>> >> "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>>
>> >> 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>>
>> >> 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 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 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
>> Phone:  (206) 667-5791
>> Fax:    (206) 667-1319
>>
>>

	[[alternative HTML version deleted]]



More information about the Bioc-devel mailing list