The current r-devel (aka R 1.7.0) now attaches the package "methods"
by
default at startup.
A new option, "defaultPackages", is set to c("methods",
"ctest") by
default, causing the .First in package base to require those two
packages at startup.
There are two main known differences from having methods attached:
- the definition of class() changes, in particular no object ever has a
NULL class. If you have code that depends on test such as
`if(is.null(class(x)))...', there may be problems.
Usually code with those sort of tests is doing a workaround of the fact
that not all objects had a class before. The best solution is usually
to ask what the code really wants to do. If you do have to retain
exactly the old behavior, one solution is to copy the version of class
and class<- from the base package and use those (as baseClass and
baseClass<-, e.g.) instead of class and class<-).
- the function plot has arguments (x,y,...) (to allow methods for the
y-axis argument) instead of (x, ...) in package base. S3-style plot
methods are still dispatched, but there are possible incompatibilities
from calls to plot() with _unnamed_ arguments (other than x) intended
for these methods.
See ?Startup for how the defaultPackages option affects startup (& for
ways to change the packages attached at startup).
--
John M. Chambers jmc@bell-labs.com
Bell Labs, Lucent Technologies office: (908)582-2681
700 Mountain Avenue, Room 2C-282 fax: (908)582-3340
Murray Hill, NJ 07974 web: http://www.cs.bell-labs.com/~jmc
> The current r-devel (aka R 1.7.0) now attaches the package "methods" by > default at startup.There's either a problem here or something is wrong on my end as I just did a rsync to R-devel and the build bombed out with: gcc -shared -L/usr/local/lib -o methods.so do_substitute_direct.o methods_list_dispatch.o method_meta_data.o slot.o class_support.o tests.o -L../../../../bin -lR ../../../../library/methods/libs/methods.so is unchanged make[5]: Leaving directory `/home/jgentry/R-devel/src/library/methods/src' make[4]: Leaving directory `/home/jgentry/R-devel/src/library/methods/src' make[4]: Entering directory `/home/jgentry/R-devel/src/library/methods' dumping R code in package 'methods' initializing class and method definitions now ...Error in setClass("VIRTUAL", sealed = TRUE, where = envir) : "VIRTUAL" has a sealed class definition and cannot be redefined Execution halted make[4]: *** [../../../library/methods/R/all.rda] Error 1 -Jeff
On Fri, 17 Jan 2003, John Chambers wrote:> There are two main known differences from having methods attached: > > - the definition of class() changes, in particular no object ever has a > NULL class. If you have code that depends on test such as > `if(is.null(class(x)))...', there may be problems. > > Usually code with those sort of tests is doing a workaround of the fact > that not all objects had a class before. The best solution is usually > to ask what the code really wants to do. If you do have to retain > exactly the old behavior, one solution is to copy the version of class > and class<- from the base package and use those (as baseClass and > baseClass<-, e.g.) instead of class and class<-).Here is one example, which makes the MASS scripts fail.> library(MASS) > correspfunction (x, ...) { if (is.null(class(x))) class(x) <- data.class(x) UseMethod("corresp", x, ...) } That used to work with matrices, and dispatch to corresp.matrix. Now a matrix has reported class "matrix" but dispatch occurs to corresp.default. The temporary fix is to remove the is.null condition. That's quite a common construction, and I think I should expect UseMethod to dispatch on the class class() reports. So it looks to me as if UseMethod needs to be altered to do so. Brian -- Brian D. Ripley, ripley@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595