R devel - Apr 2014 - [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 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

On 03/27/2014 06:31 PM, Herv? Pag?s wrote:
> On 03/27/2014 02:13 AM, Ulrich Bodenhofer wrote:
>> [...]
>>
>> 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.
>
After a while, I came back to this suggestion. Thanks, Herv?! I now 
tried it and it indeed works smoothly: all problems I mentioned - as you 
expected correctly - are resolved. It seems that BiocGenerics screws up 
my previously defined S4 generic, but leaves my S3 function untouched. 
Hmm ...

The question is whether it is good style to use S3 and S4 together. 
Actually I am reluctant to think so, but if it helps and creates no 
other problems whatsoever, why not?

Cheers,
Ulrich

On Thu, Apr 3, 2014 at 4:33 AM, Ulrich Bodenhofer
<bodenhofer@bioinf.jku.at>wrote:
> On 03/27/2014 06:31 PM, Hervé Pagès wrote:
>
>> On 03/27/2014 02:13 AM, Ulrich Bodenhofer wrote:
>>
>>> [...]
>>>
>>>
>>> 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.
>>
>>  After a while, I came back to this suggestion. Thanks, Hervé! I now
> tried it and it indeed works smoothly: all problems I mentioned - as you
> expected correctly - are resolved. It seems that BiocGenerics screws up my
> previously defined S4 generic, but leaves my S3 function untouched. Hmm ...
>
> The question is whether it is good style to use S3 and S4 together.
> Actually I am reluctant to think so, but if it helps and creates no other
> problems whatsoever, why not?
>
>
One motivation for defining S3 methods is that the base (and other non-S4)
packages define and call S3 generics, so integration with base
functionality is easier. Where an S4 generic is also present, one should
*additionally* define S4 methods corresponding to the S3 methods, because
in that context it is possible for an S4 method to take precedence over the
S3 method in a way that violates the dispatch rules regarding inheritance.
In other words, if there is a class B that extends A, any S4 method
dispatching on A will take precedence over an S3 method dispatching on B.

See ?Methods.

Cheers,
> Ulrich
>
	[[alternative HTML version deleted]]

On Thu, Apr 3, 2014 at 4:33 AM, Ulrich Bodenhofer
<bodenhofer@bioinf.jku.at>wrote:
> On 03/27/2014 06:31 PM, Hervé Pagès wrote:
>
>> On 03/27/2014 02:13 AM, Ulrich Bodenhofer wrote:
>>
>>> [...]
>>>
>>>
>>> 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.
>>
>>  After a while, I came back to this suggestion. Thanks, Hervé! I now
> tried it and it indeed works smoothly: all problems I mentioned - as you
> expected correctly - are resolved. It seems that BiocGenerics screws up my
> previously defined S4 generic, but leaves my S3 function untouched. Hmm ...
>
> The question is whether it is good style to use S3 and S4 together.
> Actually I am reluctant to think so, but if it helps and creates no other
> problems whatsoever, why not?
>
>
One motivation for defining S3 methods is that the base (and other non-S4)
packages define and call S3 generics, so integration with base
functionality is easier. Where an S4 generic is also present, one should
*additionally* define S4 methods corresponding to the S3 methods, because
in that context it is possible for an S4 method to take precedence over the
S3 method in a way that violates the dispatch rules regarding inheritance.
In other words, if there is a class B that extends A, any S4 method
dispatching on A will take precedence over an S3 method dispatching on B.

See ?Methods.

Cheers,
> Ulrich
>
	[[alternative HTML version deleted]]