[Rd] Conflicting definitions for function redefined as S4 generics

[John Chambers]

I'm sympathetic to the problem.  But, whatever my opinion, it's not likely that the basic R paradigm with respect to S3/S4 methods will change much, and certainly not for a year.

Meanwhile, let's remember the essential idea.  Every function has a corresponding implicit generic form (well, partially ignoring primitives for the moment).

The standard approach to defining methods for a non-generic is either to just use setMethod() or to use the simple form of setGeneric("foo").  EIther way, the generic function and the method refer to the package from which foo() came.  If all packages defining methods for foo() follow this pattern, the result is a single table of methods in the generic for foo() during an R session.

See the "Basic Use" section of ?setGeneric. 

The difficulties come when some package sets up a _different_ version of foo() as a generic.  This becomes a separate, incompatible, generic function. When still other packages are involved, there is a potential for methods to be divided among multiple tables.  If people feel they need to do this, they have to sort out the consequences.  Ideally, in my opinion, they should rename the function so users can choose which version to call.

Finally, even if we managed to incorporate implicit generic versions of functions in base (don't hold your breath), it's extremely unlikely that these would lop off arguments from the non-generic function.  There is no real reason to prohibit some formal arguments from being in the formal arguments to the generic. 

In a few cases, some arguments may be prohibited from being dispatched on, e.g., if those arguments have to be evaluated in a non-standard way, and that is handled by the signature= argument.  In any case, the implicitGeneric() mechanism is designed to handle such issues.  Meaning that package programming should be fairly immune to change, so long as the Basic Use is followed.

Summary: So long as the recommendations of Basic Use are followed, I don't see the problem of multiple versions.  There are other aspects of the non-inclusion of S4 in the R paradigm that cause difficulties, but basic use approach should provide one consistent table of methods for each function.

John


On Mar 27, 2014, at 2:13 AM, Ulrich Bodenhofer <bodenhofer at bioinf.jku.at> wrote:

> 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
>>        >
>> 
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel