[Bioc-devel] version argument to setClass and serialized instances

Seth Falcon sfalcon at fhcrc.org
Fri Apr 21 20:10:58 CEST 2006

I have a few questions and thoughts regarding class versioning and
serialized S4 class instances.

How is the version argument to setClass is intended to work?  It
appears to want an externalptr, but that seems odd to me.

    setClass("FOO", representation(x="numeric"), version="1.2.3")

    Error in validObject(.Object) : invalid class
    "classRepresentation" object: invalid object for slot "versionKey"
    in class "classRepresentation": got class "character", should be
    or extend class "externalptr"

The use case I'm interested in is: 

  A user has a serialized instance foo of class FOO in old.rda.  The
  class definition lives in FooPkg.  

  Suppose the class definition of FOO in FooPkg changes.  When the
  user loads the new version of FooPkg and then loads their old.rda
  file, how can the user identify the instance as one belonging to an
  old class def version?

Some thoughts:

* A related issue is how to load the appropriate class definition when
  loading a serialized S4 instance.  It makes sense to me that a
  side-effect of load("foo.rda") is that FooPkg gets loaded so that
  the instance "makes sense".  More generally, it would be cool to
  have hooks into serialization and deserialization.  That could allow
  much more robust handling of serialized instances of old definitions
  (even if it would have to happen on a class-by-class basis).

* A class definition version id might have to be an instance slot.
  One possible simple-minded implementation is to force a slot with
  some mangled name like '.class_def_version_string'.  But perhaps
  there is a more elegant approach.

One more question:

Is there a convenient way to introspect an _instance_?  The
slotNames() method seems to get data from the class definition and
doesn't report the right info for an instance that is out of date
w.r.t. to the current class defn (i.e., was deserialized after a class
defn update).

Thanks for listening.

+ seth

More information about the Bioc-devel mailing list