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, parti
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, redefin
I haven't looked at this in detail, but my guess is the following is the
distinction:
A simple call setGeneric("sort") makes a generic of the existing
function _with the existing package_:
> setGeneric("sort")
[1] "sort"
> sort
standardGeneric for "sort" defined from package "base"
function
First of all, thanks for the very interesting and encouraging replies
that have been posted so far!
Let me quickly add what I have tried up to now:
- setMethod("sort", signature("ExClust"), function(x, decreasing=FALSE,
%...%) %...% , sealed=TRUE) without any call to setGeneric(), i.e.
assumi
On 26/03/2014, 9:13 AM, Gabriel Becker 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 multip
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 wrote:
> Perhaps a patch to R such
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'
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
[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 w
