On Thu, Apr 3, 2014 at 4:33 AM, Ulrich Bodenhofer
<bodenho...@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]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
