From sfalcon at fhcrc.org  Sun Oct 29 02:13:57 2006
From: sfalcon at fhcrc.org (Seth Falcon)
Date: Sat, 28 Oct 2006 18:13:57 -0700
Subject: [Rd] Pb with .findInheritedMethods
In-Reply-To: <4543E723.4080402@r-project.org> (John Chambers's message of "Sat,
	28 Oct 2006 19:26:27 -0400")
References: <454142C1.9030809@fhcrc.org> <45415AB4.3050505@fhcrc.org>
	<454204C3.2030606@r-project.org> <45424E50.8030206@fhcrc.org>
	<4543E723.4080402@r-project.org>
Message-ID: <m2iri3q5yi.fsf@ziti.local>

John Chambers <jmc at r-project.org> writes:
> 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.

If you have written an initialize method, then it is likely because
you want to do something other than just fill slots.  A subclass will
most likely need to define its own initialize method and in this case,
I'm not sure passing ... will matter.

> 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.

Unless that isn't the behavior one desires (and I would claim this is
a rather common situation).  As part of the user interface to the
class, the developer may want to decouple the intitialization
interface from specific slot names.


+ seth




[Rd] Pb with .findInheritedMethods
Seth Falcon