Michael Lawrence
2014-Mar-26 13:44 UTC
[Rd] Conflicting definitions for function redefined as S4 generics
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@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@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@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@bioinf.jku.at <mailto:bodenhofer@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]]
Hervé Pagès
2014-Mar-26 17:54 UTC
[Rd] [Bioc-devel] Conflicting definitions for function redefined as S4 generics
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 <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> 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
>>>
>>
>>
>>
>> --
>> Gabriel Becker
>> Graduate Student
>> Statistics Department
>> University of California, Davis
>>
>
> [[alternative HTML version deleted]]
>
> _______________________________________________
> 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
Ulrich Bodenhofer
2014-Mar-27 09:13 UTC
[Rd] Conflicting definitions for function redefined as S4 generics
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 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 > > >
John Chambers
2014-Mar-27 17:06 UTC
[Rd] Conflicting definitions for function redefined as S4 generics
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, partially ignoring primitives for the
moment).
The standard approach to defining methods for a non-generic is either to just
use setMethod() or to use the simple form of setGeneric("foo").
EIther way, the generic function and the method refer to the package from which
foo() came. If all packages defining methods for foo() follow this pattern, the
result is a single table of methods in the generic for foo() during an R
session.
See the "Basic Use" section of ?setGeneric.
The difficulties come when some package sets up a _different_ version of foo()
as a generic. This becomes a separate, incompatible, generic function. When
still other packages are involved, there is a potential for methods to be
divided among multiple tables. If people feel they need to do this, they have
to sort out the consequences. Ideally, in my opinion, they should rename the
function so users can choose which version to call.
Finally, even if we managed to incorporate implicit generic versions of
functions in base (don't hold your breath), it's extremely unlikely that
these would lop off arguments from the non-generic function. There is no real
reason to prohibit some formal arguments from being in the formal arguments to
the generic.
In a few cases, some arguments may be prohibited from being dispatched on, e.g.,
if those arguments have to be evaluated in a non-standard way, and that is
handled by the signature= argument. In any case, the implicitGeneric()
mechanism is designed to handle such issues. Meaning that package programming
should be fairly immune to change, so long as the Basic Use is followed.
Summary: So long as the recommendations of Basic Use are followed, I don't
see the problem of multiple versions. There are other aspects of the
non-inclusion of S4 in the R paradigm that cause difficulties, but basic use
approach should provide one consistent table of methods for each function.
John
On Mar 27, 2014, at 2:13 AM, Ulrich Bodenhofer <bodenhofer at
bioinf.jku.at> 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
>
> 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
>> >
>>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
Hervé Pagès
2014-Mar-27 17:31 UTC
Re: [Bioc-devel] Conflicting definitions for function redefined as S4 generics
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 first4) 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@ucdavis.edu >> <mailto:gmbecker@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@gene.com <mailto:lawrence.michael@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@bioinf.jku.at <mailto:bodenhofer@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@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@fhcrc.org Phone: (206) 667-5791 Fax: (206) 667-1319
Hervé Pagès
2014-Mar-27 17:31 UTC
[Rd] [Bioc-devel] Conflicting definitions for function redefined as S4 generics
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 first4) 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
Apparently Analagous Threads
- Conflicting definitions for function redefined as S4 generics
- Conflicting definitions for function redefined as S4 generics
- Conflicting definitions for function redefined as S4 generics
- [Bioc-devel] Conflicting definitions for function redefined as S4 generics
- How to address the following: CRAN packages not using Suggests conditionally