[Rd] [Bioc-devel] Conflicting definitions for function redefined as S4 generics

[Hervé Pagès]

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 compatibility is important, but, as far as I
> got it, redefining a function or S3 generic as an S4 generic should not
> harm existing functionality (if done properly). If it turns out not to
> be a good option to do this in the base package, why not as part of the
> methods package? That will leave existing functionality of base
> unchanged and will provide a clean situation to all users/packages using
> S4.
>
> This should not create a compatibility problem on the Bioconductor side
> either, since Bioconductor releases are explicitly bound to specific R
> versions. Once again: I fully support this idea (not only for sort(),
> but also for a wide range of other functions), though, not being an R
> core team member, I do not really feel in the position to demand such a
> fundamental change.
>
> 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 BiocGenerics
> 3) leaving the problem open, mentioning in the documentation that users
> who want to use apcluster in conjunction with Bioconductor should load
> BiocGenerics first

4) define an S3 method, as mentioned in my previous post

H.

>
> As far as I got it, there seems to be no other clean way to get rid of
> the problem, right?
>
> Best regards,
> Ulrich
>
>
> On 03/26/2014 02:44 PM, 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 <gmbecker at ucdavis.edu
>> <mailto:gmbecker at 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.michael at gene.com <mailto: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 <mailto: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
>>         >
>>
>
> _______________________________________________
> Bioc-devel at 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: hpages at fhcrc.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319