similar to: Problems with S4 methods dispatching on `...` (aka dotsMethods)

Great, thanks Michael for you quick response! I started off with a question on SO because I was not sure whether this was an actual bug or I was just missing something obvious. I'm looking forward to the patch. Cheers, Andrzej On Thu, Apr 20, 2017 at 10:28 PM, Michael Lawrence < lawrence.michael at gene.com> wrote: > Thanks for pointing out these issues. I have a fix that I will

I attempted to fix it, and that example seems to work for me. It's also a (passing) regression test in R. Are you sure you're using a new enough R-devel? On Tue, Apr 25, 2017 at 2:34 AM, Andrzej Ole? <andrzej.oles at gmail.com> wrote: > Hi Michael, > > thanks again for your patch! I've tested it and I'm happy to confirm that > `callNextMethod()` works with

I ported that over. On Tue, Aug 1, 2017 at 5:50 AM, Andrzej Ole? <andrzej.oles at gmail.com> wrote: > Thank you Michael for updating the 3.4 branch, the `callNextMethod()` now > works for `...` methods as expected. However, I'm still missing your other > patch fixing the handling of arguments in `...` methods. It would be really > great if this bugfix could be integrated

Thank you Michael for updating the 3.4 branch, the `callNextMethod()` now works for `...` methods as expected. However, I'm still missing your other patch fixing the handling of arguments in `...` methods. It would be really great if this bugfix could be integrated into the 3.4 branch as well, such that the following code doesn't result in an error. Cheers, Andrzej f = function(x,

Hi Michael, thanks again for your patch! I've tested it and I'm happy to confirm that `callNextMethod()` works with methods dispatching on `...`. However, the second issue I reported still seems to be unresolved. Consider the following toy example, where the `f()` calls differ in result depending on whether the dispatch happens on a formal argument or the `...` argument. f =

>>>>> John Chambers <jmc at r-project.org> >>>>> on Sat, 10 Sep 2016 09:16:38 -0700 writes: > (Brief reply, I'm traveling but as per below, this is on my radar right now so wanted to comment.) > Two points regarding "dotsMethods". > 1. To clarify the limitation. It's not that all the arguments have to be of the same

Hi Gabriel, and thanks for answering. I'm basically just trying to find a way to use the power of `...` in more complex scenarios and I'm well aware that this might not be the best approach ;-) Regarding your actual question: "Are you suggesting methods be dispatched based on the *contents* of ... [...]?" Yes, I guess currently I kind of do - but not on the argument *names*

Dear List, I'm currently investigating if the argument dispatch mechanism based on `...` could somehow be "generalized" to scenarios that involve `r` recipients located across `c` calling stack layers *and* combined with the S4 method mechanism (for those interested see

I have been asked (by Roger; thank you for the good question, and I hope it's fine to answer to the public) : > with Pi a sparse matrix and x,y, and ones > compatible n-vectors ? when I do: >> c(t(x) %*% Pi %*% ones, t(ones) %*% Pi %*% y ) > [[1]] 1 x 1 Matrix of class "dgeMatrix" > [,1] [1,] > 0.1338527 >

Well, the benefit lies in the ability to pass along arguments via `...` to more than one recipient that use *identical argument names* and/or when these recipients are not necessarily located on the same calling stack layer. I'm *not* after a *general* change in the way arguments are dispatched/functions are called as I'm actually a big friend of keepings things quite explicit (thus

Dear UseRs, Does anyone know when exactly the validity is checked in S4? Documentation is silent:(. Here is a small example: setClass("test1",representation(a="numeric")) setMethod("initialize","test1", function(.Object,...){ a<-runif(1) ## here slot "a" is initialized ## callNextMethod(.Object,a=a,...)

Hi, Given a simple three class hierarchy: A <-- B <-- C I want to define an initialize method for each class such that when I call new("C", x=5), the initialize methods for A and B are used to incrementally build the object. When I do what seems obvious to me using callNextMethod, I get an infinite recursion. An example follows... setClass("A",

(Brief reply, I'm traveling but as per below, this is on my radar right now so wanted to comment.) Two points regarding "dotsMethods". 1. To clarify the limitation. It's not that all the arguments have to be of the same class, but there must be one class that they belong to or subclass. (So, as in the example in the documentation, the method could be defined for a class

Can someone explain what the problem is when I use the generating function? And how to get debug() to stop in the Superclass initialize method? ---- source ----- setClass("Superclass", representation(id = "character"), contains = "VIRTUAL") setMethod("initialize", signature(.Object = "Superclass"),

Hello, I experienced a strange behaviour of callNextMethod when used in either initialize or any other S4 function method definition. Help says callNextMethod calls the next inherited method for the current function from where it is called with the same actual (non missing) arguments. This is OK. The problem appears when some formal arguments (in particular, S4 objects) of this function are

Dear all, Maybe, I am doing something wrong, but using R-2.5.0 on my Intel-Mac, I have problems using function callNextMethod() in method initialize. I am loading the following code as file "testS4.R": setClass("baseClass", representation(myname = "character", mydir = "character", "VIRTUAL"),

Hi, Strange things happen. Here is a simple example: > setClass("A", contains="integer") > setMethod("as.matrix", "A", function(x, ...) t(callNextMethod())) Creating a generic function for ?as.matrix? from package ?base? in the global environment [1] "as.matrix" > a <- new("A", 1:3) > as.matrix(a)

Janko, I'm not entirely sure I understand your proposal. Are you suggesting methods be dispatched based on the *contents* of ... (ie which arguments are in there)? This seems like it would be pretty different from how dispatch behaves now, which is entirely class based. Even the dispatching based on ... via dots methods is class based, having nothing to do AFAIK with the argument names. From

Dear all, I am just writing the documentation file for S4 class 'QualTreeSet' and get the following warning with R CMD check: * checking for missing documentation entries ... WARNING Undocumented S4 methods: generic 'initialize' and siglist 'QualTreeSet' All user-level objects in a package (including S4 classes and methods) should have documentation entries. See the

Hello R users, I am trying to make a my first package and I get an error that I can understand. The package is build out of three files (one for functions, 1 for s4 classes and 1 for s4 methods). Once I source them I run package.skeleton( name="TDC" ) within a R session and I get Creating directories ... Creating DESCRIPTION ... Creating Read-and-delete-me ... Saving functions and