[R] creating list with 200 identical objects

[Rainer M Krug]

On Tue, Jun 2, 2009 at 10:44 AM, Wacek Kusnierczyk
<Waclaw.Marcin.Kusnierczyk at idi.ntnu.no> wrote:
> Rainer M Krug wrote:
>> Thanks a lot Wacek for this clear description of the problem - I was
>> not aware, that it is that complex.
>> I definitely did not consider the initialize() function in writing my code.
>>
>> But as I only want to allocate the space for the objects, it does not
>> matter here. But when I write a simulation and want to initialize it
>> with two hundred different individuals, this definitely becomes
>> crucial - thanks again for this clarification and the very useful
>> references (especially [2] for the moment).
>>
>> Am I right that all assignments of classes via <- or -> are by value
>> and NOT by reference? So when
>>
>> setClass('foo',
>>        representation=representation(content='character'),
>>        prototype=list(content='foo'))
>>
>> A <- new("foo")
>> B <- A
>>
>
> i guess [sic] that what happens at this point is the usual thing:  B
> refers to the *same* object, which now has an increased accession counter.

As far as I understand it, a "class" is an abstract definition of a
certain type of object, which can be instantiated by using new(). This
returns an "object", or an instance of the class. Each of these
"objects" allocate a separate memory. Therefore, they can hold
different values in their "slots".
So if you are referring to the same "object", this would mean that it
points to the same memory space, and consequently contains the same
values.
But if the two instances of the "class" can hold different data,
everything is fine.

>
>> B is a different object then A, i.e. changes in B are not reflected in
>> A and vice versa, but they have the same content.
>>
>
> well.  i guess [sic] that when you assign to a slot of b, it is that
> object that is reproduced, which also triggers a reproduction of the
> instance object itself (note:  without 'new' and any initializer being

This sounds reasonable and makes perfect sense.

> called).  however, this does not happen if the slot is an environment,
> because r won't reproduce an environment on assignment.  in this case,
> you still have A and B being the same object, with modified content:

I must admit, I have never looked into environments - I probably
should - they sound interesting.

>
>    setClass('foo',
>        representation=representation(foo='environment'),
>        prototype=list(foo=new.env()))
>
>    a = new('foo')
>    b = a
>    a at foo$bar = 'bar'
>    b at foo$bar
>    # "bar"
>
>
> to be sure, you may want to check with the sources -- i haven't done it
> yet, hence the guesswork.
>
>
>> It seems that if foo has a slot O containing an object of class
>> "fooInFoo", this object O also copied by value. I.e. when, following
>> above,
>>
>> setClass('foo2',
>>        representation=representation(content='character'),
>>        prototype=list(content='fooInFoo'))
>> setClass('foo',
>>        representation=representation(content='character', O='foo2'),
>>        prototype=list(content='foo', O=new('foo2')))
>> A <- new("foo")
>> B <- A
>>
>> A at O@content <- "AAAAAAAAAAAAAA"
>> A at O@content
>>   [1] "AAAAAAAAAAAAAA"
>> B at O@content
>>   [1] "fooInFoo"
>>
>> Is this always the case? and is there a way of copying by reference
>> (or passing an object to a function by reference)?
>>
>
> using environments provides a straightforward way to pass by reference,
> because that's how they are passed.  (the claim that r passes by value,
> made here and there, is incorrect and misleading, for this and other
> reasons.)

Good to know.

>
> otherwise, r's object systems -- s3 and s4 -- are so good that people
> have been inventing their own ways to deal with the trouble.  For
> example, R.oo, available from cran, is a package with
>
> "Methods and classes for object-oriented programming in R with or
> without references. [...] This is a cross-platform package implemented
> in pure R that defines standard S3 classes without any tricks."

I have looked into R.oo, but not further - probably I should. But if I
can do the same without additional packages, I prefer to avoid them.

Rainer

>
> vQ
>
>



-- 
Rainer M. Krug, Centre of Excellence for Invasion Biology,
Stellenbosch University, South Africa