[Rd] Conflicting definitions for function redefined as S4 generics

[Duncan Murdoch]

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.michael at 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 <
>> bodenhofer at 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
>>> bodenhofer at bioinf.jku.at <mailto:bodenhofer at bioinf.jku.at>
>>> http://www.bioinf.jku.at/ <http://www.bioinf.jku.at>
>>>
>>> ______________________________________________
>>> R-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>>          [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
>