[R] inheritence in S4

[Martin Morgan]

cgenolin at u-paris10.fr wrote:
>> The code example is incomplete, so I don't really know why one version 
>> assigned y=3 for you and the other did not; for me, neither version 
>> did the assignment.
> 
> I probably add the return in the mail without imagining il will change 
> things.
> 
> My question was more on the use of ... versus the absence of ...
> You anwer me by correcting my bug. So I can use callNextMethod with or 
> without ... :
> 
> setClass("B",representation(y="numeric"))
> setMethod("initialize","B",
>          function(.Object,..., yValue){
>              return(callNextMethod(.Object, ..., y=yValue))
>          })
> 
> new("B",yValue=3)                   #1
> try(new("B",yValueee=3))            #2 
> try(new("B",yValue=3,yValueee=3))   #3
> 
> setMethod("initialize","B",
>          function(.Object, yValue){
>              return(callNextMethod(.Object, y=yValue))
>          })
> new("B",yValue=3)                    #4
> try(new("B",yValueee=3))             #5
> try(new("B",yValue=3,yValueee=3))    #6
> 
> I undersand that 1 and 4 work. I understand that 2 and 5 do not work 
> since yValue is missing
> I understand that 6 does not work since yValueee is not a valid argument
> But I would expect that 3 will work since it get a value for yValue and 
> yValueee can be one of the ...

The first challenge is to understand how ... works (maybe from 'An 
Introduction to R', section 10.4?)

 > f <- function(...) names(list(...))

 > f(x=1)
[1] "x"
 > f(x=1, y=2)
[1] "x" "y"

Probably ok so far. Now

 > g <- function(..., x) f(..., z=x) # 'g' transmits 'x' as 'z'
 > g(x=1)
[1] "z"
 > g(y=1,x=2)
[1] "y" "z"

or

 > h <- function(..., x) f(...) # 'h' consumes 'x'
 > h()
NULL
 > h(x=1)
NULL
 > h(y=1)
[1] "y"
 > h(y=1,x=1)
[1] "y"

For instance, g passes an argument to f that consisting of (what g 
received as) ... and z. f is expects ..., and z ends up as part of that 
list.

What happens with initialize? The default method is described on 
?initialize, where the signature is

initialize(.Object, ...)

with

      ...: Data to include in the new object.  Named arguments
           correspond to slots in the class definition.
[snip]

in #3, your callNextMethod results in the default method seeing ... 
containing an argument yValueee=3. Since yValueee does not match a slot, 
R responds with an error

  > Error in .nextMethod(.Object, ..., y = yValue) :
   invalid names for slots of class "B": yValueee

With the ..., a class extending B can rely on the default method to fill 
in slots with provided arguments.

setClass("C", representation=representation(c="numeric"), contains="B")
new("C", yValue=1, c=2) # works with ... in B's initialize method

Without ..., a class extending B would have to write an initialize 
method that fills in slots (and checks validity) itself, repeating the 
work already implemented in initialize,ANY-method.

> It does not...
> 
> Christophe
> 
> ----------------------------------------------------------------
> Ce message a ete envoye par IMP, grace a l'Universite Paris 10 Nanterre
> 
> 
> 


-- 
Martin Morgan
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M2 B169
Phone: (206) 667-2793