R devel - Sep 2010 - Assignment to a slot in an S4 object in a list seems to violate copy rules?

Dear R-developers

I came across the following issue, which I find strange:

setClass("A", representation(a = "numeric"))
B <- list()
myA <- new("A", a = 1)
B$otherA <- myA
B$otherA at a <- 2
myA at a

Assigning a new value to slot 'a' in the _copy_ of myA stored
in B$otherA changes the original value of myA -- this was
surprising to me, and I believe not supposed to be so. This
"copy-through" only happens once.

B$otherA at a <- 1
myA at a

Other ways to access the list entries (B[["otherB"]] and B[[1]]) seem
to work as expected, and it seems that the issue is related to the fact
that 'otherA' does not already exist in B.

Is there something I have missed? Thanks.

Best, Niels	

sessionInfo()

R version 2.12.0 Under development (unstable) (2010-09-13 r52905)
Platform: i386-apple-darwin9.8.0/i386 (32-bit)

locale:
[1] da_DK.UTF-8/da_DK.UTF-8/C/C/da_DK.UTF-8/da_DK.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base


-- 
Niels Richard Hansen                     Web:   www.math.ku.dk/~richard	
Associate Professor                      Email: Niels.R.Hansen at math.ku.dk
Department of Mathematical Sciences             nielsrichardhansen at gmail.com
University of Copenhagen                 Skype: nielsrichardhansen.dk	
Universitetsparken 5                     Phone: +45 353 20783 (office)	
2100 Copenhagen ?                               +45 2859 0765 (mobile)
Denmark

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.




-- 
Peter Dalgaard
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd.mes at cbs.dk  Priv: PDalgd at gmail.com