[Rd] Conflicting definitions for function redefined as S4 generics
Ulrich Bodenhofer
bodenhofer at bioinf.jku.at
Thu Mar 27 10:13:31 CET 2014
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
> >
>
More information about the R-devel
mailing list