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

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
        >