[Rd] [Bioc-devel] Conflicting definitions for function redefined as S4 generics

Wed Mar 26 18:54:38 CET 2014

Hi,

I agree. I can't think of an easy way to avoid this kind of clashes
between BioC and non-BioC S4 generics, other than by having things
like sort() already defined as an S4 generic in base R.

Note that, just having setMethod("sort", ...) in your package Ulrich, 
and not putting a setGeneric() statement, is usually the right thing
to do. Because then there will be no clash as long as everybody else
does the same thing. That's because if several packages with a
setMethod("sort", ...) statement are loaded, an implicit S4 generic
is created when the 1st package is loaded, and then "sort" methods
are attached to it when subsequent packages are loaded.

Unfortunately, the implicit S4 generic one gets when doing this
doesn't always have an optimum signature. For example, for sort()
we get dispatch on 'x' *and* 'decreasing':

   > sort
   standardGeneric for "sort" defined from package "base"

   function (x, decreasing = FALSE, ...)
   standardGeneric("sort")
   <environment: 0x230bf28>
   Methods may be defined for arguments: x, decreasing
   Use  showMethods("sort")  for currently available ones.

This is why in BiocGenerics we have:

   setGeneric("sort", signature="x")

The downside of this is that now if you load BiocGenerics after your
package, a new S4 generic is created for sort(), which overrides the
implicit S4 generic that was created when your package was loaded.
Of course we wouldn't need to do this in BiocGenerics if the implicit
S4 generic for sort() had the correct signature, or if this setGeneric()
statement we have in BiocGenerics was somewhere in base R.

Another reason for explicitly promoting some base R functions into
S4 generics in BiocGenerics is to have a man page for the generic.
That gives us a place to document some aspects of the S4 generic that
are not covered by the base man page. That's why BiocGenerics has
things like:

   setGeneric("nrow")

   setGeneric("relist")

The signatures of these generics is the same as the signature of
the implicit generic! But these explicit generics can be exported
and documented.

Back to the original issue: In the particular case of sort() though,
since base::sort() is an S3 generic, one possible workaround for you
is to define an S3 method for your objects.

Cheers,
H.

On 03/26/2014 06:44 AM, Michael Lawrence wrote:
> That might be worth thinking about generally, but it would still be nice to
> have the base generics pre-defined, so that people are not copy and pasting
> the definitions everywhere, hoping that they stay consistent.
>
>
> On Wed, Mar 26, 2014 at 6:13 AM, Gabriel Becker <gmbecker at ucdavis.edu>wrote:
>
>> Perhaps a patch to R such that generics don't clobber each-other's method
>> tables if the signatures agree? I haven't dug deeply, but simply merging
>> the method tables seems like it would be safe when there are no conflicts.
>>
>> That way this type of multiplicity would not be a problem, though it
>> wouldn't help (as it shouldn't) if the two generics didn't agree on
>> signature or both carried methods for the same class signature.
>>
>> ~G
>>
>>
>> On Wed, Mar 26, 2014 at 4:38 AM, Michael Lawrence <
>> lawrence.michael at gene.com> wrote:
>>
>>> The BiocGenerics package was designed to solve this issue within
>>> Bioconductor. It wouldn't be the worst thing in the world to depend on the
>>> simple BiocGenerics package for now, but ideally the base generics would
>>> be
>>> defined higher up, perhaps in the methods package itself. Maybe someone
>>> else has a more creative solution, but any sort of conditional/dynamic
>>> approach would probably be too problematic in comparison.
>>>
>>> Michael
>>>
>>>
>>>
>>> On Wed, Mar 26, 2014 at 4:26 AM, Ulrich Bodenhofer <
>>> bodenhofer at bioinf.jku.at
>>>> wrote:
>>>
>>>> [cross-posted to R-devel and bioc-devel]
>>>>
>>>> Hi,
>>>>
>>>> I am trying to implement a 'sort' method in one of the CRAN packages I
>>> am
>>>> maintaining ('apcluster'). I started with using setMethod("sort", ...)
>>> in
>>>> my package, which worked fine. Since many users of my package are from
>>> the
>>>> bioinformatics field, I want to ensure that my package works smoothly
>>> with
>>>> Bioconductor. The problem is that the BiocGenerics package also
>>> redefines
>>>> 'sort' as an S4 generic. If I load BiocGenerics before my package,
>>>> everything is fine. If I load BiocGeneric after I have loaded my
>>> package,
>>>> my setMethod("sort", ...) is overridden by BiocGenerics and does not
>>> work
>>>> anymore. A simple solution would be to import BiocGenerics in my
>>> package,
>>>> but I do not want this, since many of this package's users are outside
>>> the
>>>> bioinformatics domain. Moreover, I am reluctant to include a dependency
>>> to
>>>> a Bioconductor package in a CRAN package. I thought that maybe I could
>>>> protect my setMethod("sort", ...) from being overridden by BiocGeneric
>>> by
>>>> sealed=TRUE, but that did not work either. Any ideas are gratefully
>>>> appreciated!
>>>>
>>>> Thanks a lot,
>>>> Ulrich
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>> *Dr. Ulrich Bodenhofer*
>>>> Associate Professor
>>>> Institute of Bioinformatics
>>>>
>>>> *Johannes Kepler University*
>>>> Altenberger Str. 69
>>>> 4040 Linz, Austria
>>>>
>>>> Tel. +43 732 2468 4526
>>>> Fax +43 732 2468 4539
>>>> bodenhofer at bioinf.jku.at <mailto:bodenhofer at bioinf.jku.at>
>>>> http://www.bioinf.jku.at/ <http://www.bioinf.jku.at>
>>>>
>>>> ______________________________________________
>>>> R-devel at r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>
>>>
>>>          [[alternative HTML version deleted]]
>>>
>>>
>>> ______________________________________________
>>> R-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>>
>>
>> --
>> Gabriel Becker
>> Graduate Student
>> Statistics Department
>> University of California, Davis
>>
>
> 	[[alternative HTML version deleted]]
>
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
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 at fhcrc.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319