[Bioc-devel] any interest in a BiocMatrix core package?

Martin Maechler maechler at stat.math.ethz.ch
Thu Nov 2 18:38:49 CET 2017

>>>>> Martin Morgan <martin.morgan at roswellpark.org>
>>>>>     on Thu, 2 Nov 2017 06:17:19 -0400 writes:

    > On 11/02/2017 05:00 AM, Martin Maechler wrote:
    >>>>>>> "ML" == Michael Lawrence <lawrence.michael at gene.com>
    >>>>>>> on Wed, 1 Nov 2017 14:13:54 -0700 writes:
    >> > Probably way easier to add the generics to the Matrix >
    >> package and everyone just depends on that.
    >> Yes!  It is 'Recommended' and comes with every R
    >> installation, and has had many such matrix S4 methods in
    >> place for > 10 years, notably for dealing with (large)
    >> sparse matrices.
    >> Honestly, I (as co-maintainer of Matrix, principal
    >> maintainer for several years now) had been a bit
    >> surprised and frustrated that the 'matrixStats'
    >> initiative had started w/o any contact with the Matrix
    >> package maintainers and initially has not ever tried to
    >> use Matrix package classes or functionality (and this is
    >> still the case now AFAICS).
    >> I'm happy to coordinate with maintainers of bioc packages
    >> about which generics (and classes !) to use and export,
    >> etc.

    > One issue is that Matrix is a relatively large package
    > (well, I wonder if that's a reasonable statement, given
    > the Bioc dependencies and data involved, but perhaps in
    > general...) and hence 'overkill' to obtain a collection of
    > generics. Is there any prospect for factoring out the
    > definition of the generics from implementation of the
    > methods?  Re-purposing stats4 ?

    > Martin Morgan

Hmm..  we have quite a few  setGenericImplicit()  statements in
the methods package already, notably for  'colSums' and friends,
and so other decent citizen packages do *NOT*  setGeneric() at
all on these ... and of course, Matrix _is_ a decent citizen in
the R package universe.

Instead of to stats4, I'm pretty sure we should only consider
what functions should be added to the implicit generics already
provided by the 'methods' package itself.

Could it be that (some of) you are not properly aware of
implicit generics?

If you start 'R --vanilla' you can say

> implicitGeneric("colSums")
standardGeneric for "colSums" defined from package "base"

function (x, na.rm = FALSE, dims = 1, ...) 
<bytecode: 0x6cb4798>
<environment: 0x6cab560>
Methods may be defined for arguments: x, na.rm, dims
Use  showMethods("colSums")  for currently available ones.

so I think it is clear how *any* decent package has to define
methods for colSums(), and if they do, there should not be any conflicts.

I think the problem is with S3 methods, not with S4 ones, where
the implicit generics I understand where made for dealing with
several packages writing methods for the same generic without
one of the packages taking precedence.

Martin Mächler

    >> Best, Martin Maechler ETH Zurich (and R core team)
    >> > On Wed, Nov 1, 2017 at 1:59 PM, Hervé Pagès >
    >> <hpages at fredhutch.org> wrote:
    >> >> That's probably a good idea but a clean solution would
    >> >> need to involve all players, including the Matrix >>
    >> package. Right now there are conflicts for some S4 >>
    >> generics defined in Matrix and in BiocGenerics >>
    >> (e.g. rowSums). I'm not sure that moving rowSums from >>
    >> BiocGenerics to a new MatrixGenerics package would >>
    >> address this.  Unless MatrixGenerics is on CRAN and >>
    >> Matrix depends on it ;-)
    >> >>
    >> >> How likely is this to happen?
    >> >>
    >> >> H.
    >> >>
    >> >>
    >> [............]
    >> _______________________________________________
    >> 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.

More information about the Bioc-devel mailing list