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 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.
I don't think R should base the decision on the signature.
There are two very different situations where this might come up. In
one, package A and package B might both define a generic named foo()
that happens to have the same signature, but with nothing in common.
That should be allowed, and should behave the same as when they both
create functions with the same name: it should be up to the user to
specify which generic is being called. If R merged the two generics
into one, there would be chaos.
The other situation is more likely to apply to this case. It sounds as
though both apcluster and BiocGenerics are creating a sort() generic by
promoting the base package S3 generic into an S4 generic. Clearly they
should not be creating separate generics, there's just one.
I don't know if there's something wrong with the way apcluster or
BiocGenerics are doing things, or something wrong with the way the
methods package is creating the generic, but it sure looks like a bug
somewhere.
Duncan Murdoch
~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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
