similar to: Fixes/additions to methods package

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

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

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

I am another person who has had trouble documenting S4 classes and (particularly) methods. The methods package itself is pretty cool by the way, but it is a pity that there are as yet no guidelines on S4 in the "Writing R Extensions" document. I have actually put together a guide on S4 documentation myself for the use of my own lab which is at

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

John Chambers suggested that I forward this thread (first posted to r-help) along to r-devel... Thanks, Kevin -----Original Message----- From: John Chambers [mailto:jmc@research.bell-labs.com] Sent: Tuesday, August 06, 2002 6:31 PM To: Bartz, Kevin Cc: r-help@stat.math.ethz.ch Subject: Re: [R] [ and setMethod conflict? Definitely something funny going on, but perhaps a little less sweeping

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,

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

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

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

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

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

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