[R] Why S4 method is not visible from another package?

[Martin Morgan]

Gábor Csárdi wrote:
> On Thu, Sep 17, 2009 at 5:59 PM, Martin Morgan <mtmorgan at fhcrc.org> wrote:
>> Gábor Csárdi wrote:
>>> Dear All,
>>>
>>> maybe this is something obvious, I seem to be incapable of
>>> understanding how S4 works.
>>>
>>> So, in package 'A' I defined a "summary" method for my class:
>>>
>>> setMethod("summary", signature(object="ListHyperGResult"),
>>>           function(object, pvalue=pvalueCutoff(object), categorySize=NULL) {
>>>              "whatever"
>>>           })
>>>
>>> "ListHyperGResult" has a subclass, "GOListHyperGResult":
>>>
>>> setClass("GOListHyperGResult",
>>>          representation=representation(conditional="logical"),
>>>          contains="ListHyperGResult",
>>>          prototype=prototype(testname="GO"))
>>>
>>> The summary method is exported in the NAMESPACE:
>>>
>>> exportMethods("summary")
>>>
>>> Package 'B' depends on package 'A', this is stated in the
>>> 'DESCRIPTION' file. If I call 'summary' on a 'GOListHyperGResult' in
>> Hi Gabor
>>
>> It is not S4 alone, but S4 + name spaces that are giving you problems.
>>
>> You probably want to Import: A rather than depends, and importFrom(A,
>> summary).
>>
>> As it stands, inside the B name space, you find base::summary, whereas
>> you've defined a method on summary that has been promoted to a generic
>> in one of the packages that A imports (probably AnnotationDbi).
>>
>> This is a little bit of a guess; at some level it might seem more
>> appropriate to Import: AnnotationDbi and importFrom(AnnotationDbi,
>> summary) (or wherever the generic for summary that you are trying to use
>> is created).
> 
> Martin, thanks, this solved the problem.
> 
> But isn't this a bit weird? Suppose I am the author of package 'B' and
> want to use the classes defined in package 'A'. I don't care about
> exact details of the implementation of these classes, I don't want to
> know that they are based on something in package 'C' (AnnotationDbi,
> really). But I still have to import specific functions from 'C'.
> 
> Moreover, suppose the author of 'C' changes 'summary', e.g. puts it
> into another package, 'D' and makes 'C' importing it from 'D'. This
> will break my package, 'B' as well.

Yes it seems a bit weird at first. But there really is a generic
C::summary that is different from base::summary, and could have, e.g., a
different signature, so you really are interested in C::summary and not
base::summary. Partly the (pleasant, in the long run) surprise here is
that R is separately managing both base::summary and C::summary, and
doing so in a way (via name spaces) that allows control over which will
be used. A second surprise, to the author of C, is that their package
has now become valuable enough to others that C can no longer be changed
at will.

Martin

> 
> Anyway, thanks a lot for your help, Best Regards,
> Gabor
> 
>> Martin
>>
> 
>