On 03/27/2014 06:31 PM, Hervé Pagès wrote:
On 03/27/2014 02:13 AM, Ulrich Bodenhofer wrote:
[...]
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
On Thu, Apr 3, 2014 at 4:33 AM, Ulrich Bodenhofer
bodenho...@bioinf.jku.atwrote:
On 03/27/2014 06:31 PM, Hervé Pagès wrote:
On 03/27/2014 02:13 AM, Ulrich Bodenhofer wrote:
[...]
For the time being, it seems I have three options:
1) not supplying the sort() function yet (it is not yet
On 03/27/2014 02:13 AM, Ulrich Bodenhofer 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
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,
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,
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
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
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.eduwrote:
[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
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
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
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.eduwrote:
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
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.
assuming
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 (x,
15 matches
Mail list logo
