similar to: Changes to the methods package

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,

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.

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.

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 >

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

markus.jantti@iki.fi wrote: > > Full_Name: Markus Jantti > Version: 1.5.1 > OS: GNU/Linux Unstable (Sid) > Submission from: (NULL) (193.166.59.44) > > I was trying to get the package yags 3.20 by Vince Carey > <stvjc@channing.harvard.edu> > to run, but - after successfull installation -- loading the library failed with > the > message > > >

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 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

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

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 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 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

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()