[Rd] Conflicting definitions for function redefined as S4 generics

[Ulrich Bodenhofer]

I fully agree, Michael, that this would be a great thing to have! I have 
often wondered why R and the standard packages are still sticking so 
much to the old-style S3 flavor though S4 is part of standard R. I 
acknowledge that backward compatibility is important, but, as far as I 
got it, redefining a function or S3 generic as an S4 generic should not 
harm existing functionality (if done properly). If it turns out not to 
be a good option to do this in the base package, why not as part of the 
methods package? That will leave existing functionality of base 
unchanged and will provide a clean situation to all users/packages using S4.

This should not create a compatibility problem on the Bioconductor side 
either, since Bioconductor releases are explicitly bound to specific R 
versions. Once again: I fully support this idea (not only for sort(), 
but also for a wide range of other functions), though, not being an R 
core team member, I do not really feel in the position to demand such a 
fundamental change.

For the time being, it seems I have three options:

1) not supplying the sort() function yet (it is not yet in the release, 
but only in my internal devel version)
2) including a dependency to BiocGenerics
3) leaving the problem open, mentioning in the documentation that users 
who want to use apcluster in conjunction with Bioconductor should load 
BiocGenerics first

As far as I got it, there seems to be no other clean way to get rid of 
the problem, right?

Best regards,
Ulrich


On 03/26/2014 02:44 PM, 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 
> <mailto: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 <mailto: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 <mailto: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
>         >
>