similar to: library(methods): setMethod with "ANY" fails. (PR#1317)

Hello, I have defined a new class > setClass("myclass", representation(min = "numeric", max = "numeric")) and want to write accessor functions, so that for > foo = new("myclass", min = 0, max = 1) > min(foo) # prints 0 > max(foo) # prints 1 At first i created a generic function for "min" > setGeneric("min",

I'm seeing weird issues in methods initialization, i.e. loading marrayClasses loads Biobase, and when explicitly done, as in library(Biobase) library(marrayClasses) is fine, but when Biobase is loaded via a require statement in marrayClasses' .First.Lib, I end up with: Warning message: In the method signature for function "coerce", class "exprSet" has no

after this setClass("A") setGeneric("bar", function(x, y) standardGeneric("bar")) setMethod(bar, signature(x="A", y="A"), function(x, y) {}) setMethod(bar, signature(x="A", y="ANY"), function(x, y) {}) the method for signature c("A", "A") contains package information > str(getMethod(bar,

I have some questions about S4 style methods and generics. First of all, is there any way of using default values for arguments in the generics/methods? My own experiments show that such arguments are always ignored. The green book seems to be silent on this matter. The second question is about using a non-trivial function body for generics. Page 351 of the green book gives an example of this

Hi, while playing with the `methods' package I was not able to find what the recommended way of dealing with the following problem is. Suppose there is a generic function `foo' and two functions `foo.default' and `foo.formula', in the classical way: foo <- function(y, ...) UseMethod("foo") foo.default <- function(y, ...) {} foo.formula <- function(formula,

I noticed this oddity about [ and setMethod. First, I define testFunc, which sorts a data frame by the first column and returns the entries that aren't NAs, and testIt, which runs testFunc repeatedly on a random large data frame, each time saving the return into a dummy placeholder (for demonstration's sake). > require(methods) Loading required package: methods [1] TRUE > testFunc

I noticed this oddity about [ and setMethod. First, I define testFunc, which sorts a data frame by the first column and returns the entries that aren't NAs, and testIt, which runs testFunc repeatedly on a random large data frame, each time saving the return into a dummy placeholder (for demonstration's sake). > require(methods) Loading required package: methods [1] TRUE > testFunc

Dear all, I can't see how setGeneric() works. I know perfectly well how to define library(methods); setClass("Square", representation(side="numeric")); # Will become the default method. getArea <- function(object) { stop(paste("Method getArea() is not defined for this class:", data.class(object))); } setMethod("getArea",

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

My question has two parts. The first is with regard to the frame or environment in which generic functions are defined in packages. It seems as though they are defined (i.e. exist as objects) in frame 1, even when defined in a package. The following is a short example: setClass("track",representation(x="numeric",y="numeric")) plotTrack <- function(x,y,...)

Hi, I found the following on Windows 2000/NT R Version 1.9.1 (2004-06-21) (also Version 1.9.0): The S4 group "Math" doesn't work as documented; i.e., "log", "log10", "gamma" and "lgamma" are included in the documentation but don't work. See example code below. Moreover, what about 'genericForPrimitive' which is used in

Full_Name: Tim Keitt Version: 1.5 OS: Linux Submission from: (NULL) (128.227.201.237) The function "setMethod" makes the following call to "insertMethod": allMethods <- insertMethod(allMethods, signature, fnames[1:length(signature)], asMethodDefinition(definition, signature)) If I understand insertMethod correctly, the third argument should be the names of the

I do lots of analyses on large microarray data sets so memory use and speed and both important issues for me. I have been trying to estimate the overheads associated with using formal S4 data objects instead of ordinary lists for large data objects. In some simple experiments (using R 1.7.1 in Windows 2000) with large but simple objects it seems that giving a data object a formal class

Hi, Please consider the following trivial example. In the sample code I first define a class MVCa using composition. This class contains a slot of type list. Next I define an inheritance relation using the function setIs -> MVCa "is a" list. Then I define a function printlength which prints the list-length which is defined for the type "list". If I call this function

Hi, The following question might come from my (deep) misunderstanding of the concepts in the package 'methods'. I have a class 'A', and a class 'B' inheriting 'A' (so defined with 'setClass' and the parameter 'contains="A"'. The class A has a method 'mymethod'. A call to 'showMethods("mymethod")' return the

I'm trying to write a package which uses classes/methods as defined in the `methods' package. I have a single .R file which defines the class and various methods for that class. At the top of the file I have require(methods) and then setClass("myclass", ...) setGeneric("intersect") setMethod("intersect", "myclass", function(x,y) ...) I noticed

1. Is it always the case that when defining generic functions in a package, the package needs to be installed as a binary package to avoid having the generic functions in the .GlobalEnv? 2. Defining a generic function in a "non-binary" package triggers a check warning $ R CMD check ... ... * checking for code/documentation mismatches ... WARNING Objects

Hi, we have some questions concerning the definition of new arithmetic methods. In our package "distr" (on CRAN) we define some new arithmetic methods for "+", "-", "*", "/". After loading "distr" the corresponding arithmetic methods work. Now, if we define a new class and also a new method for one of the arithmetic methods

In the last few days I've received couple of messages pointing out that our SparseM package fails to install on the patched version of 1.7.0. Laurent Gaultier kindly suggested that replacing: setGeneric("as.matrix.csr") by setGeneric("as.matrix.csr", function(x, nrow, ncol, eps) standardGeneric("as.matrix.csr")) was sufficient to fix the problem.

Fine with me as long as eliminating the inconveniences associated with it can be put on the roadmap. The alias instability and the fact that the user has no way to know if s/he should do ?`foo,numeric-method` or ?`foo,numeric,ANY-method` to find the method has been a long-standing problem. H. On 3/21/19 21:29, Michael Lawrence wrote: If we started over, I'd try to avoid this sort of