similar to: Old-style classes: bug fix & request

One of the changes some packages are noticing from the recent modifications to methods is warnings of "undefined classes" during installation when the package extends S3 classes or uses them as slots UNLESSS they have been declared in a setOldClass() call. The green book "strongly recommends" declaring S3 classs this way (pp 449-451). The warnings on undeclared classes

Some changes committed today to the r-devel (1.6.0) version of the methods package: 1. The function setOldClass has been added as per the green book, p. 450. The point in this case is not conversion as in the green book so much as allowing old-style classes to be included in signatures given to setMethod. This worked before (with a warning), but old-style inheritance couldn't be picked up.

Some changes to the implementation of S4 classes in the methods package will be committed to the r-devel version, probably later today. They should be largely back-compatible (exception noted below) but they are fairly extensive, so this is an advance notice. The changes form the first of a two-stage change aimed at making the implementation more consistent with R semantics, in particular with

An extensive set of changes to the methods package has been committed today to allow non-exported classes from packages with namespaces (and some related fixes in dealing with generic functions from namespaces as well). The namespace mechanism requires packages to export any class definitions that are part of the API. Unfortunately, NOT exporting classes has never really worked. The problem was

A new version was checked in to r-devel today. These are the main changes: 1. Objects from the methods package are no longer copied into base. As a result, the behavior of data.class and all.equal should be the same whether methods are attached or not. (The methods package no longer uses data.class.) Also, detaching the methods package should restore the behavior of class() to the S3

Dear colleagues: This summer, the ASA will award a new prize for statistical software. This note is to encourage you to apply or nudge someone you know to apply. The award is for software that contributes to better use of computing in statistical research and applications, written while the applicant was a student. There is a $1,000 prize plus the opportunity to give an invited talk at the

The current version of the methods package now has a namespace. Packages using S4 methods and classes can have NAMESPACE files. New directives can be included in NAMESPACE files to import and export classes and methods. Namespaces allow cleaner definition of the API for packages, and are needed for future improvements to R. NOTE: This is a major revision. In principle, it should be back

We're starting work on an R package and corresponding S-Plus library to help programmers write software that will work in both systems. Some descriptions and downloadable software are available on the Omegahat web site, at http://www.omegahat.org/SLanguage/ The strategy, as described there, is to be as back-compatible within R and within S-Plus as possible, but provide tools and guidelines

I'm about to commit some changes to the methods package. Before downloading the revised code, note the following. Because the changes involve a revised version of storage for the methods definitions, you will need to re-install any packages that contain method definitions, from their source code. Otherwise the methods will look as if they've disappeared from the generic functions. The

There is a version of the methods package committed today that does dispatch in C for these functions. This should considerably speed up programs that define methods for these functions (specifically, having methods should only marginally affect the existing computations for the same function on basic vectors and objects). This is the first of several steps needed. Not quite all primitives are

I had better mention this one separately, since until it's settled you need a workaround. If you define methods for primitives now, this does NOT create an explicit generic function for, say, "[", so that the original primitive computations still run. This means that the method dispatch has to be turned on for that function somehow else. The proposal is that the library() and

A new version of the package has been committed to the r-devel branch. There are a lot of changes, mostly non-visible, many of those to tighten up some possible problems. For example, slot assignment now checks the validity of the value being assigned, and basic classes cannot be overriden. There is a version of the promptClass function by Vince Carey, to produce shell of documentation for a

A few recent changes: - as announced to R-core, the package now has a version of the plot function with formal arguments (x, y, ...) that allow methods to be defined for x and/or y. ?setMethod has some examples. - The "basic classes" have been made somewhat more complete (class "structure" was added, along with relations among it, "matrix", "array",

Now that 1.5 is released, some changes have been committed to the r-devel version of the methods package. They are mostly bug fixes (or making things work more as users would expect) in two areas: 1. new classes that extend one of the basic datatypes that have attributes but had no class attribute in S3 (e.g., "matrix" or "ts"). The previous code didn't handle the

1. UseMethod (via usemethod in objects.c) now uses the definition of class() to dispatch, with the methods package attached (dataClass(x)) and without (attr(x, "class")). Packages using a construction of the form if(is.null(class(x))) class(x) <- data.class(x) UseMethod("foo") should now get similar dispatch with the methods package attached. 2. all.equal and some of its

Some fixes have been made to check a few errors better & to report something like the correct error message in other cases. - setMethod will now refuse to set a method for a primitive function for a basic class ("[<-" for "matrix", for example). Previously the method was set but never dispatched. (For a few days, the change prohibited some valid methods for operators,

A number of changes were committed today. Mainly: 1. It should now be possible to install packages using classes and methods in a more straightforward way, and with or without saved images (saved images are still recommended for efficiency). The idea is to be able to write class & method definitions in a package source, with default `where' argument, as per examples in the green book.

An example sent by Ross Ihaka points out a non-obvious step needed to export the results of setAs(). The as() mechanism can't use ordinary method dispatch because the second argument is the name of a class, not an object from the class. So it uses a "helper" function, coerce(), and sets methods for that function. Therefore, if you want to export the results of setAs(), at the

(I enlarged this mail from r-core to r-devel since it's an interesting question for general discussion.) Douglas Bates wrote: > > In a recent r-patched I notice that when df is a data.frame > as(df, "list") does not propagate the names whereas as.list(df) does. > Is this intentional? Well, it's explicit anyway. The as() function uses method dispatch for coerce()

The r-devel (1.4) code has C implementations now of the class and class<- functions in package methods, and also of as.environment. The last brings up a question (it shows up in the isas-tests test suite). as.environment(NULL) is NULL. Seems like it has to be, since NULL is the environment associated with package:base. But is.environment(NULL) is FALSE, which is also fairly natural, if we