From tlumley at uw.edu  Thu Sep 30 17:39:34 2010
From: tlumley at uw.edu (Thomas Lumley)
Date: Thu, 30 Sep 2010 08:39:34 -0700
Subject: [Rd] Assignment to a slot in an S4 object in a list seems to
 violate copy rules?
In-Reply-To: <05A9E180-7213-436D-9321-351B0F7E8882@gmail.com>
References: <4CA49C81.6020704@math.ku.dk>
	<05A9E180-7213-436D-9321-351B0F7E8882@gmail.com>
Message-ID: <AANLkTikkvmG4PjVLykmGmcg99dC_m0vXmvWo-FOzUUdz@mail.gmail.com>

On Thu, Sep 30, 2010 at 8:15 AM, peter dalgaard <pdalgd at gmail.com> wrote:
>
> On Sep 30, 2010, at 16:19 , Niels Richard Hansen wrote:
>
>> setClass("A", representation(a = "numeric"))
>> B <- list()
>> myA <- new("A", a = 1)
>> B$otherA <- myA
>> B$otherA at a <- 2
>> myA at a
>
> R version 2.12.0 Under development (unstable) (2010-09-13 r52905)
> Platform: i386-apple-darwin9.8.0/i386 (32-bit)
>
> --- not anymore, it seems: ---
>> setClass("A", representation(a = "numeric"))
> [1] "A"
>> B <- list()
>> myA <- new("A", a = 1)
>> B$otherA <- myA
>> B$otherA at a <- 2
>> myA at a
> [1] 1
>> sessionInfo()
> R version 2.12.0 alpha (2010-09-29 r53067)
> Platform: x86_64-apple-darwin10.4.0 (64-bit)
>
> So somewhere in the last 162 commits, this got caught. Probably r52914, but it looks like it hasn't been recored in NEWS (and it should be as this was apparently a live bug, not an obscure corner case):
>
> r52914 | luke | 2010-09-15 19:06:13 +0200 (Wed, 15 Sep 2010) | 4 lines
>
> Modified applydefine to duplicate if necessary to ensure that the
> assignment target in calls to assignment functions via the complex
> assignment mechanism always has NAMED == 1.
>

Yes, that was the one.  It was reported as a bug back then too, and
there was quite a bit of discussion that ended up with Luke's fix.

      -thomas

-- 
Thomas Lumley
Professor of Biostatistics
University of Washington, Seattle



[Rd] Assignment to a slot in an S4 object in a list seems to violate copy rules?
Thomas Lumley