From jmc at r-project.org  Sun Oct 29 01:26:27 2006
From: jmc at r-project.org (John Chambers)
Date: Sat, 28 Oct 2006 19:26:27 -0400
Subject: [Rd] Pb with .findInheritedMethods
In-Reply-To: <45424E50.8030206@fhcrc.org>
References: <454142C1.9030809@fhcrc.org> <45415AB4.3050505@fhcrc.org>
	<454204C3.2030606@r-project.org> <45424E50.8030206@fhcrc.org>
Message-ID: <4543E723.4080402@r-project.org>

Herve Pages wrote:
> ....
> More generally I don't see what's wrong with not passing
> to callNextMethod all the arguments coming from the call
> to new:
>
>     setClass("A", representation(toto="integer"))
>     setMethod("initialize", "A", function(.Object, toto0) {.Object at toto
>     <- as.integer(toto0); .Object})
>     new("A", 45.1)
>
>     setClass("Ab", contains="A")
>     setMethod("initialize", "Ab", function(.Object, x, y)
>     callNextMethod(.Object, x*y+1))
>     new("Ab", 5, 2)
>   

As I mentioned, this relates to writing methods for initialize().   
Imagine someone else extends the class "Ab", for which you wrote a 
method.  If they add slots to their class and you do not pass down ... 
to callNextMethod(), then you have blocked users from setting values for 
those slots in calls to new(), since the ... argument is thrown away by 
your method.

So in your example, it's more socially responsible to add "..." as a 
formal argument to your method, and then to pass it on to callNextMethod():

   setMethod("initialize", "Ab", function(.Object, x, y, ...)
    callNextMethod(.Object, x*y+1, ...))

The other aspect to this is that the last specialized method in your chain of class definitions should end up with:
   callNextMethod(.Object, ...)
Then the default initialize() method will set values for named slots.  Again, the point is to allow others to extend your class definitions.



>
> Regards,
>
> H.
>
>




[Rd] Pb with .findInheritedMethods
John Chambers