Hi,
I agree. I can't think of an easy way to avoid this kind of clashes
between BioC and non-BioC S4 generics, other than by having things
like sort() already defined as an S4 generic in base R.
Note that, just having setMethod("sort", ...) in your package Ulrich,
and not putting a setGeneric() statement, is usually the right thing
to do. Because then there will be no clash as long as everybody else
does the same thing. That's because if several packages with a
setMethod("sort", ...) statement are loaded, an implicit S4 generic
is created when the 1st package is loaded, and then "sort" methods
are attached to it when subsequent packages are loaded.
Unfortunately, the implicit S4 generic one gets when doing this
doesn't always have an optimum signature. For example, for sort()
we get dispatch on 'x' *and* 'decreasing':
> sort
standardGeneric for "sort" defined from package "base"
function (x, decreasing = FALSE, ...)
standardGeneric("sort")
<environment: 0x230bf28>
Methods may be defined for arguments: x, decreasing
Use showMethods("sort") for currently available ones.
This is why in BiocGenerics we have:
setGeneric("sort", signature="x")
The downside of this is that now if you load BiocGenerics after your
package, a new S4 generic is created for sort(), which overrides the
implicit S4 generic that was created when your package was loaded.
Of course we wouldn't need to do this in BiocGenerics if the implicit
S4 generic for sort() had the correct signature, or if this setGeneric()
statement we have in BiocGenerics was somewhere in base R.
Another reason for explicitly promoting some base R functions into
S4 generics in BiocGenerics is to have a man page for the generic.
That gives us a place to document some aspects of the S4 generic that
are not covered by the base man page. That's why BiocGenerics has
things like:
setGeneric("nrow")
setGeneric("relist")
The signatures of these generics is the same as the signature of
the implicit generic! But these explicit generics can be exported
and documented.
Back to the original issue: In the particular case of sort() though,
since base::sort() is an S3 generic, one possible workaround for you
is to define an S3 method for your objects.
Cheers,
H.
On 03/26/2014 06:44 AM, 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>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> 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
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
------------------------------------------------------------------------
*Dr. Ulrich Bodenhofer*
Associate Professor
Institute of Bioinformatics
*Johannes Kepler University*
Altenberger Str. 69
4040 Linz, Austria
Tel. +43 732 2468 4526
Fax +43 732 2468 4539
bodenho...@bioinf.jku.at <mailto:bodenho...@bioinf.jku.at>
http://www.bioinf.jku.at/ <http://www.bioinf.jku.at>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis
[[alternative HTML version deleted]]
_______________________________________________
bioc-de...@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax: (206) 667-1319
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
