similar to: Update on S4 Method dispatch changes

A revision of r-devel 2.4.0 is being committed today with changes to method and class management. The changes are internal but extensive. All packages that use S4 methods and classes need to be reinstalled from source to use the new version. The main effects are to speed up method caching and dispatch, and to fix some problems with selecting inherited methods. The new design is also

Hi, I encounter a problem with method dispatch with S4 classes, using the 'sealed' parameter in setClass. See that example below: setClass("X",representation(x="numeric"),sealed=TRUE) setGeneric("foo",function(x) standardGeneric("foo")) setMethod("foo",signature("X"),function(x) print("foo(X)")) x <-

List, In order to get rid of some old, unreadable S3 code in package sp, I'm trying to rewrite things using S4 methods. Somewhere I fail, and I cannot sort out why. In order to isolate the problem, I created two functions, doNothing<- and dosth, and both should do nothing. The issue is that in most cases they do nothing, but in some cases dosth(obj) changes the class of obj and breaks with

Would we really need the special class or would simply checking the formals of the method against those of the generic be simple and fast enough? On Thu, Jan 29, 2015 at 9:41 AM, John Chambers <jmc at r-project.org> wrote: > I wouldn't want to add more to the current approach; if someone would like > to devote some time, the much preferable idea IMO would be to replace the >

Dear all, I have a question regarding setIs and method dispatch in S4 classes: Consider the following example: ##################################################### ## A02 "contains" A01 by setIs: setClass("A01", representation(a="numeric",b="numeric")) setClass("A02", representation(a="numeric",d="numeric"))

Hello, I am writing an interface to some functions from the CRAN package pamr, which is poorly written. I have a S4 method I declared with setMethod. I'd like to provide a signature of "pamrtrained" which is the class of object that training creates. The last two lines of code of pamr.train are : class(junk) = "pamrtrained" junk How can I dispatch on these kinds

I'm trying to track down a problem I'm having in the Zelig package and have stumbled across a very odd difference in the method dispatch for a derived S4 class. Specifically, I have an object of class ZeligS4vglm, which is a subclass of vglm and vlm respectively (these are from the VGAM package). summary() at the command line prompt of this object calls summary.vglm, which is what I

I wish it didn't have to depend on the name '.local'. Back when I wrote a lot of S4 methods I avoided the auto-generated .local and named the local function something that made sense so that is was easier for a user to track down the source of an error. E.g., define the generic QQQ with numeric and integer methods: setGeneric("QQQ", function(x, ...)NULL)

What a delicious example! (I'm taking the liberty of sharing it with r-devel, since it raises some good issues.) You have two questions, presumably: 1 - how could the order of the setMethod calls make a difference in the results? 2 - what's causing the infinite loop & how could it be avoided, reliably? Second question first. The danger sign is the "vector" method:

Dear list, is it possible that method dispatch checks for superclasses/virtual classes before checking "ANY"? I'd like to build a generic initialization method for all my Reference Class (say "MyDataFrame") objects by having them inherit from class, say "MyRefClassVirtual" (which would have to be a virtual S4 class; there are no virtual Reference Classes,

On 05/10/2015 08:19 AM, Martin Morgan wrote: > Loading an S4 object from a file without first loading the library sometimes (?, > the example below and actual example involves a virtual base class and the show > generic) leads to incorrect dispatch (to the base class method). > > The attached package reproduces the problem. It has The package was attached but stripped; a version is

Hello, I've been attempting to make a generic method that dispatches on the first argument, which can be either an S3 or an S4 class. This is as far as I've gotten. Any suggestions about what to try next ? library(aroma.affymetrix) library(GenomicRanges) setGeneric("analyse", function(x, y, ...) standardGeneric("analyse")) setMethodS3("analyse",

I use 2 packages that both implement a S4 plot method, where one package depends on the other (the bioconductor package globaltest which depends on multtest). When the plot method is used from within the package, it seems the default plot method is used, and an error is generated. When the method is invoked from the console, the plot is created correctly. I have reproduced this with 2 small

I have been running into difficulties with dispatching on an S4 class defined in the SparseM package, when the method calls are inside a function passed as the f= argument to optimize() in functions in the spdep package. The S4 methods are typically defined as: setMethod("det","matrix.csr", function(x, ...) det(chol(x))^2) that is within setMethod() rather than by name before

On Thu, Jan 29, 2015 at 7:57 AM, John Chambers <jmc at r-project.org> wrote: > > On Jan 28, 2015, at 6:37 PM, Michael Lawrence <lawrence.michael at gene.com> wrote: > >> At this point I would just due: >> >> formals(body(method)[[2L]]) >> >> At some point we need to figure out what to do with this .local() confusion. > > Agreed, definitely.

I wouldn't want to add more to the current approach; if someone would like to devote some time, the much preferable idea IMO would be to replace the whole mechanism. Here's one suggestion: 1. have a class, say "nonConformingMethod" for method definitions that diverge in the argument list. 2. the internal dispatch code checks the class of the selected definition (this can

Full_Name: Colin A. Smith Version: 1.8.0 OS: Mac OS X 10.2.6 Submission from: (NULL) (216.102.90.18) Both Biobase and my package annaffy use S4 classes to define methods for "[". Both packages use the save image method of installation. (See annaffy 1.0.3 in BioC CVS.) Depending on how both packages are loaded, the Biobase definitions seem to be getting masked out: >

Hi, I ran into the following peculiarity involving S4 method dispatch and namespaces. I develop a package which have a namespace and which depends on 'pixmap' package, which itself does not have a namespace. Now, in my package I have a class which has a slot for objects from class "pixmap" and I want to have a "plot" method for this new class. Not to clutter the

Hi list, I've got a class B that contains a slot obj of class A. I'd like to be able to call all the methods of class A directly on objects of class B as if I had called the method on slot obj. This without overloading all methods of class A to work on class B. I don't define B as an extension of A, because I want class B to also work with objects of classes that inherit from

Loading an S4 object from a file without first loading the library sometimes (?, the example below and actual example involves a virtual base class and the show generic) leads to incorrect dispatch (to the base class method). The attached package reproduces the problem. It has setClass("A") setClass("B", contains="A") setMethod("show", "A",