similar to: setAs() and namespaces

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

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

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

This seemed too advanced for r-help and is related to the recent discussion of character vectors in dataframes. Following Brian Ripley's most excellent advice, we are moving to a world in which character vectors in dataframes are always of class AsIs. The cool way of doing this seemed to be the following: > cat(c("x", "y", "z"), file = "test.txt",

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

(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

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 >