Bug 8112 - Bug in copying of S4 objects
Summary: Bug in copying of S4 objects
Status: NEW
Alias: None
Product: R
Classification: Unclassified
Component: S4methods (show other bugs)
Version: old
Hardware: ix86 (32-bit) Windows 32-bit
: P5 normal
Assignee: Jitterbug compatibility account
URL:
Depends on:
Blocks:
 
Reported: 2005-08-31 23:48 UTC by Jitterbug compatibility account
Modified: 2005-09-02 08:33 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jitterbug compatibility account 2005-08-31 23:48:09 UTC
From: Duncan Murdoch <murdoch@stats.uwo.ca>
If I have an S4 object, and I make a copy, changes to the original 
aren't reflected in the copy:

 > setClass("foo", representation(slot="numeric"))
 > x <- new("foo", slot=1)
 > y <- x
 > x@slot <- 2
 > y
An object of class "foo"
Slot "slot":
[1] 1

This is as it should be.  However, if I call the slot assignment 
function in a funny way, y *does* receive the changes:

 > x <- new("foo", slot=1)
 > y <- x
 > assign("x", "@<-"(x, "slot", 2))
 > y
An object of class "foo"
Slot "slot":
[1] 2

This happens in the current R-devel in Windows, and R-patched too.

 > version
          _
platform i386-pc-mingw32
arch     i386
os       mingw32
system   i386, mingw32
status   Under development (unstable)
major    2
minor    2.0
year     2005
month    08
day      31
svn rev  35467
language R

Duncan Murdoch

Comment 1 Jitterbug compatibility account 2005-09-02 06:36:16 UTC
From: Luke Tierney <luke@stat.uiowa.edu>
Another variant of what is probably the same issue:

     > setClass("foo", representation(a = "numeric"))
     [1] "foo"
     > f <- function() x@a <<- 2
     > x <- new("foo",a=1)
     > y <- x
     > f()
     > x
     An object of class “fooâ€Â
     Slot "a":
     [1] 2

     > y
     An object of class “fooâ€Â
     Slot "a":
     [1] 2

luke

On Wed, 31 Aug 2005, murdoch@stats.uwo.ca wrote:

> If I have an S4 object, and I make a copy, changes to the original
> aren't reflected in the copy:
>
> > setClass("foo", representation(slot="numeric"))
> > x <- new("foo", slot=1)
> > y <- x
> > x@slot <- 2
> > y
> An object of class "foo"
> Slot "slot":
> [1] 1
>
> This is as it should be.  However, if I call the slot assignment
> function in a funny way, y *does* receive the changes:
>
> > x <- new("foo", slot=1)
> > y <- x
> > assign("x", "@<-"(x, "slot", 2))
> > y
> An object of class "foo"
> Slot "slot":
> [1] 2
>
> This happens in the current R-devel in Windows, and R-patched too.
>
> > version
>          _
> platform i386-pc-mingw32
> arch     i386
> os       mingw32
> system   i386, mingw32
> status   Under development (unstable)
> major    2
> minor    2.0
> year     2005
> month    08
> day      31
> svn rev  35467
> language R
>
> Duncan Murdoch
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

-- 
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:      luke@stat.uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu
Comment 2 Jitterbug compatibility account 2005-09-02 08:33:26 UTC
From: Luke Tierney <luke@stat.uiowa.edu>
I've poked in the source a bit.  Here are some notes in case someone
has time to look into this.

The main internal difference between <<- and <- for complex
assignments is that <- calls EnsureLocal which calls duplicate on the
value of the left hand side value if NAMED == 2.  In principle I don't
tink this should be necessary, but it means that assignment functions
called for <- assignments will not see NAMED == 2.  This protects
agains internal assignment functions that destructively modify without
looking at NAMED, which is what @<- and slot<- do.  But <<- does not
do this defensive duplicating, hence the problem with <<-.  Similar
problems occur if structures contain environments used to implement
reference behaviour since the copying stops at the environment.

The appropriate fix is to insure that @<- and slot<- respect NAMED and
duplicate when NAMED == 2, as attr<- does.  This will require either
making @<- and slot<- into SPECIALSXP's or some sort of
underhandedness to allow them to remain closures.  One possibility
might be to define a SPECIALSXP that looks at the NAMED value of the
object argument (by inspecting the promise before it is forced).  This
can then be passed into the internal R_set_slot function via .Call.

luke

On Thu, 1 Sep 2005, Luke Tierney wrote:

> Another variant of what is probably the same issue:
>
>    > setClass("foo", representation(a = "numeric"))
>    [1] "foo"
>    > f <- function() x@a <<- 2
>    > x <- new("foo",a=1)
>    > y <- x
>    > f()
>    > x
>    An object of class “fooâ€Â
>    Slot "a":
>    [1] 2
>
>    > y
>    An object of class “fooâ€Â
>    Slot "a":
>    [1] 2
>
> luke
>
> On Wed, 31 Aug 2005, murdoch@stats.uwo.ca wrote:
>
>> If I have an S4 object, and I make a copy, changes to the original
>> aren't reflected in the copy:
>> 
>> > setClass("foo", representation(slot="numeric"))
>> > x <- new("foo", slot=1)
>> > y <- x
>> > x@slot <- 2
>> > y
>> An object of class "foo"
>> Slot "slot":
>> [1] 1
>> 
>> This is as it should be.  However, if I call the slot assignment
>> function in a funny way, y *does* receive the changes:
>> 
>> > x <- new("foo", slot=1)
>> > y <- x
>> > assign("x", "@<-"(x, "slot", 2))
>> > y
>> An object of class "foo"
>> Slot "slot":
>> [1] 2
>> 
>> This happens in the current R-devel in Windows, and R-patched too.
>> 
>> > version
>>          _
>> platform i386-pc-mingw32
>> arch     i386
>> os       mingw32
>> system   i386, mingw32
>> status   Under development (unstable)
>> major    2
>> minor    2.0
>> year     2005
>> month    08
>> day      31
>> svn rev  35467
>> language R
>> 
>> Duncan Murdoch
>> 
>> ______________________________________________
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
>
>

-- 
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:      luke@stat.uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu
Comment 3 Jitterbug compatibility account 2005-10-08 12:27:00 UTC
NOTES:
 Cause has been identified (see R-core list)
Hard to fix without a performance hit
Comment 4 Jitterbug compatibility account 2007-04-15 11:09:26 UTC
Audit (from Jitterbug):
Sat Oct  8 09:27:37 2005	ripley	changed notes
Sat Oct  8 09:27:37 2005	ripley	moved from incoming to Low-level
Sun Apr 15 06:09:26 2007	ripley	moved from Low-level to S4methods