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 <bodenho...@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 <gmbec...@ucdavis.edu
>> <mailto:gmbec...@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.mich...@gene.com <mailto:lawrence.mich...@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
>> <bodenho...@bioinf.jku.at <mailto:bodenho...@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@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
