[Rd] Version information for S4 classes --- elementary version management

From: Peter Ruckdeschel <peter.ruckdeschel_at_web.de>
Date: Mon, 13 Oct 2008 21:22:07 +0200


we are about to update some class definitions in our distrXXX family of packages, so I would be eager to know whether there are plans in R Core to implement some version management tools for S4 classes as described in section 7.4 in JMC's "Green Book". In his recent book (continuing the color scheme, is it to be called the "Yellow Book"? :-), this topic has not been taken up again, so we are not sure whether there still is the goal to go into this direction...

We have already implemented some "individual" sort of (class) version management in our packages, but as this issue does not only concern our packages, some standardized proceding would be desirable.

AFAICS, in R 2.8.0, by default when save()ing/load()ing single S4 objects, the corresponding class definitions are not saved/restored along, while they are saved() and again restored on load() by default when producing an image by save.image(), although an existing class definition will not be overwritten.

So when load()ing an (old) S4 object, by default there will be no information about the class definition at save() time available. Of course, conceptually, such information would best be stored in the respective classRepresentation object; however, as this one does not get save()d automatically along with an object, we might think of alternatives. It might at least be a compromise to store the some version information as a special slot to every object of any S4 class.

For S4 classes defined in packages (which should make for the vast majority of them), default information could be obtained from the package version tag in the DESCRIPTION file. The rationale behind this is that an updated class definition would at least be traceable to one particular package version, while on the other hand the package version string is not a "large" object.

Based on this package version information, (elementary) version management could then be provided by means of generic functions

getClassVersion() [as described in the Green Book, 7.4] conv2NewVersion() ## by default issuing an error ("Not yet defined") isOldVersion() ## true or false; by default NA

Defining particular methods for his classes, a package maintainer could then issue specific warnings or --- at its best --- even provide coercing methods.

What do you think about this?

Best, Peter

R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Mon 13 Oct 2008 - 19:25:38 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Tue 14 Oct 2008 - 01:30:19 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.

list of date sections of archive