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
>