[R] Re: S4 method inheritance

[Robert Gentleman]

Ross Boylan wrote:
> On Tue, May 24, 2005 at 06:27:56AM -0700, Robert Gentleman wrote:
> 
>>
>>Duncan Murdoch wrote:
>>
>>>Ross Boylan wrote:
>>>
>>>
>>>>On Mon, 2005-05-23 at 14:41 -0700, Ross Boylan wrote:
>>>>....
>>>>
>>>>
>>>>
>>>>>Finally, I'm a bit concerned that one article mentioned that S4
>>>>>inheritance, in practice, is used mostly for data, not methods (Thomas
>>>>>Lumley, R News 4(1), June 2004: p. 36).  Am I going down a road I
>>>>>shouldn't travel?
>>>>>
>>>>
>>>>Hmm, maybe I just found out.  If B is an S4 subclass of A (aka extends
>>>>A), how does B's method foo invoke A's foo?
>>>
>>>
>>>Your question doesn't make sense in S4.  In S4, classes don't have 
>>>methods, generics have methods.  There's no such thing as "B's method" 
>>>or "A's method".
>>>
>>>You might get what you want with foo(as(bObject, "A")) if bObject is an 
>>>instance of class B.
>>>
>>>
>>>>The question assumes that A's foo was defined as an in place function,
>>>>so there's no (obvious) named object for it, i.e,
>>>>setMethod("A", signature(blah="numeric"), function(x) something)
>>>
>>In general it may be best to think of a generic function as a 
>>dispatching mechanism. For S4 methods are associated with a specific 
>>generic function. 
> 
> "specific" generic is a reference to the ability to define generics
>  within the context of a particular package?


Well, more that you can identify one (either explicitly by its package 
[ie. fully-qualified name], or implicitly by the fact that it is first 
on the search path - the former being prefered). But the notion is that 
there is one and you have asked that your method be made available to 
that one generic function for dispatch. This is in contrast to S3 - 
where no such functionality exists - that I know of; under S3 any method 
is a method for all generic functions of the correct name and the 
programmer has no (easy) control. Under S4 methods are not really 
ordinary functions, should not be called directly and are invoked only 
via calls to the generic (you can of course break all of those rules).

> 
>>A generic knows about all methods that are associated 
>>with it, and about no others. 
> 
> Presumably setMethod does the association.  Is the where argument
> intended to identify which generic method to pick?  The fact that
> there is not a "package" argument to setMethod, as there is to
> setGeneric, is a little confusing to me.
> 
> 

  I believe that is the documented behavior. Yes the where argument 
should allow you complete specificity. I will leave it to the auther to 
clarify differences between the where and package arguments in the call 
to setGeneric (or you, if you care to explore the code).

>>Thus in S4, the little tiff over who owns 
>>label goes away - they both do - different packages can define
>>generic 
> 
> "They" is two different packages?  Or is this a reference to my
> original confusion about class vs generic ownership of a method?
> 

  It is the two packages. The S langauge allows for the same symbol to 
be bound to different values in different namespaces (in R that is 
becoming explicit, in SPlus it is less so, but still generally true). I 
can think of no good reason to treat generic functions, or any other 
first class object, differently.

HTH,
  Robert

> 
>>functions for label, or anything else they care to, and users can write 
>>methods for specific generic
  functions and associate them with a
>>generic.
> 
> ...
> 
>> HTH
>>   Robert
> 
>