similar to: Re: as(df, "list") does not propagate names

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

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

Right. The methods such as as.data.frame.numeric don't get dispatched, basically because RSMethods tries to interpret class(x) in the S4 sense (so, e.g. a numeric vector has class "numeric"). Problems can then come from different semantics for S3-style and S4-style methods. The older methods don't dispatch on the mode of vectors (or equivalently, on the value of

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

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.

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,

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

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.

Bug fix: A bug introduced in version 1.6 failed to "initialize" some old-style (aka "S3") classes, producing possible warning messages if those classes were used in the signature of a method in the methods package. The real bug, though, was that old-style inheritance could not be included, until the setOldClass function was provided. Initializing the methods package now

Peter Dalgaard BSA wrote: > > gregory_r_warnes@groton.pfizer.com writes: > > > Under R 1.3.0 on Solaris and Windows NT there seems to be a bug in == when > > applied to elements of a list, particularly when one of the elements is of > > mode integer: > > > > > list(1) == list(1) > > [1] FALSE > > > 1 == list(1) > >

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

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

aa056@chebucto.ca wrote: > > Using the same settings in config.site as were used for R-1.4.1, > R-1.5.0 fails to build. > > ./configure --enable-R-shlib > > Using defaults and using PPro optimizations, the build failed in > package methods: > > dumping R code in package 'methods' > gmake[4]: *** [../../../library/methods/R/all.rda] Error 139 >