[R] inheritence in S4

[Martin Morgan]

cgenolin at u-paris10.fr wrote:
> Hi Martin
> 
> I am re reading all the mail we exchange with new eyes because of all 
> the thing I learn in the past few weeks. That very interesting and some 
> new question occurs...
> 
> ***********************************
> Once, you speak about callGeneric :
> 
> setClass("A", representation(x="numeric"))
> setClass("C", contains=c("A"))
> 
> setMethod("show", "A", function(object) cat("A\n"))
> setMethod("show", "C", function(object) {
>   callGeneric(as(object, "A"))
>   cat("C\n")
> })
> 
> new("C")
> 
> Considere the following definition (that you more or less teach me with 
> your yesterday remarques...) :
> 
> setMethod("show", "C", function(object) {
>   callNextMethod()
>   cat("C\n")
> })
> 
> In this case, is there any difference between the former and the latter ?
> Which one would you use ?

callNextMethod is the right thing to do for this case. callGeneric is 
useful in a very specific case -- when dispatching from within a 
so-called 'group generic' function. But this is an advanced topic.

> (I get that in more complicate case, for example if
> setClass("C", contains=c("A","B")), it might be more complicate to use 
> the latter, right ?)

The right thing to do in this case is to sit down with the rules of 
method dispatch, and figure out what the 'next' method will be. A common 
alternative paradigm is to have a plain function (not visible to the 
user, e.g., not exported in a package name space) that several different 
methods all invoke, after mapping their arguments appropriately. The 
methods provide a kind of structured interface to the function, making 
sure arguments are of the appropriate type, etc. The function does the 
work, confident that the arguments are appropriate.


> *************************
> This works :
> 
> setMethod("initialize","B",
>          function(.Object,..., yValue){
>              callNextMethod(.Object, ..., y=yValue)
>              return(.Object)
>          })
> new("B",yValue=3)
> 
> but this does not :
> 
> setMethod("initialize","B",
>          function(.Object, yValue){
>              callNextMethod(.Object, y=yValue)
>              return(.Object)
>          })
> new("B",yValue=3)
> 
> Why ?
> Is there any help page about ... ?

Both 'work' in the sense that an object is returned (by the way, no need 
to use 'return' explicitly). And actually the examples on some of the 
man pages do not include '...', so this is really my opinion rather than 
the 'right' way to do things.

In an object-oriented sense, initialize,B-method should really just deal 
with it's own slots; it shouldn't have to 'know' about either classes 
that it extends (A) or classes that extend it. And it shouldn't do work 
that inherited methods (i.e., initialize,ANY-method) do. In the second 
form above, without the ..., there is no way for the initialize,A-method 
to see arguments that might be relevant to it (e.g., values to be used 
to initialize its slots). So initialize,B-method would have to do all 
the work of initializing A. This is not good design.


> **************************
> showMethods gives the list of all the method. Is there a way to see all 
> the method for a specific signature IN THE ORDER they will be call by 
> callNextMethod ?
> If ANY <- D <- E, a method that will gives :
> 
> Function "initialize":
> .Object = "E"
> .Object = "D"
> .Object = "ANY"

There is, but I have never been able to figure it out in detail or to 
feel confident that I was using functions that were meant to be used for 
this purpose by the user (as opposed to by the methods package).

John Chambers posted recently to the R-devel mailing list about changes 
to the internal representation of methods and classes.

https://stat.ethz.ch/pipermail/r-devel/2008-March/048729.html

I have not explored the new functions Dr. Chambers mentions; to use them 
requires the 'devel' version of R, not 2.6.2. Any questions they 
generate should definitely be addressed to the R-devel mailing list.

Best,

Martin

> Thanks for your help
> And happy easter eggs !
> 
> Christophe
> 
> 
> ----------------------------------------------------------------
> Ce message a ete envoye par IMP, grace a l'Universite Paris 10 Nanterre
> 
> 
>