Skip to content

S4 class redefinition

2 messages · Ross Boylan

Original
Ross Boylan
# 
I haven't found much on S4 class redefinition; the little I've seen
indicates the following is to be expected:
1. setClass("foo", ....)
2. create objects of class foo.
3. execute the same setClass("foo", ...) again (source the same file).
4. objects from step 2 are now NULL.

Is that the expected behavior (I ran under R 2.7.1)?

Assuming it is, it's kind of unfortunate.  I can wrap my setClass code
like this
if (! isClass("foo")) setClass("foo", ....)
to avoid this problem.  I've seen this in other code; is that the
standard solution? 

I thought that loading a library was about the same as executing the
code in its source files (assuming R only code).  But if this were true
my saved objects would be nulled out each time I loaded the
corresponding library.  That does not seem to be the case.  Can anyone
explain that?

Do I need to put any protections around setMethod so that it doesn't run
if the method is already defined?

At the moment I'm not changing the class defintion but am changing the
methods, so I can simply avoid running setClass.

But if I want to change the class, most likely by adding a slot, what do
I do?  At the moment it looks as if I'd need to make a new class name,
define some coerce methods, and then locate and change the relevant
instances.  Is there a better way?

Thanks.
Ross Boylan
Ross Boylan
#
On Tue, 2009-06-30 at 12:58 -0700, Ross Boylan wrote:
I'm sorry; step 4 is completely wrong.  The objects seem to be
preserved.  Some slightly modified questions remain.

Is it safe to reexecute identical code for setClass or setMethod when
you have existing objects of the class around?

Is there any protection, such as checking for existing definitions, that
is recommended before executing setClass or setMethod?

If you want to change a class or method, and have existing objects, how
do you do that?

Can scoping rules lead to situations in which some functions or methods
end up with references to the older version of the methods?  One example
is relevant to class constructors, and shows they can:

Here's a little test
+   function(x) x+c()
[1] 7
[1] 7
[1] 28

So the old definition is frozen in the inner function, for which it was
captured by lexical scope.  Although definition of maker is not redone
after trivial is redefined, maker's default argument does get the new
value of trivial.  

Methods add another layer.  I'm hoping those with a deeper understanding
than mine can clarify where the danger spots are, and how to deal with
them.

Thanks.
Ross