similar to: missing() fails to detect missing

Fascinating. Or, well, not. Failing to use a method signature that is compatible with the generic is a no-no. So your bug seems to me to be outside the bounds of how R is supposed to be used. So don't do that. On April 17, 2024 4:25:38 PM PDT, "Boylan, Ross via R-help" <r-help at r-project.org> wrote: >When a generic (S4) has an argument with a default followed by ...,

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*

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

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

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 >

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

hi. below is a small test case (hopefully minimal, though i'm still a bit confused about initializers). i would have guessed (and maybe i still would have been right) that one could re-use the name of a generic function for functions with different numbers of arguments. in the case below, class A's bB() queries the status of a single A object, so bB(A) (where here "A" is an

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

I think I understand what you're saying now, but I'm still kind of missing the benefit from the approach. As far as I can tell just giving foo formals for the arguments you want it to catch gives you the end result you want, doesn't it? And if the generic has ... in it, you can (if you're very careful) add formals to specific methods that would capture arguments not meant for

Hi all, I recently encountered some unexpected behavior with S4 generics dispatching on `...`, which I described in http://stackoverflow.com/questions/43499203/use-callnextmethod-with-dotsmethods TL;DR: `callNextMethod()` doesn't work in methods dispatching on `...`, and arguments of such methods are resolved differently than the arguments of methods dispatching on formal arguments. Could

(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

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 tried the following (relevant excerpt only) setMethod("likelihood", signature(spec="Specification", covs="vector", states="vector"), function(spec, covs, states) { #### setMethod("likelihood", signature(model="Model", path="matrix"), function(model, path) { This

>>>>> Martin Maechler >>>>> on Sat, 29 Jun 2019 10:33:10 +0200 writes: >>>>> peter dalgaard >>>>> on Fri, 28 Jun 2019 16:20:03 +0200 writes: >> > On 28 Jun 2019, at 16:03 , Martin Maechler <maechler at stat.math.ethz.ch> wrote: >> > >> >>>>>> Henrik Bengtsson

I run checks with R-devel rev. 76756 on several of my packages which use S4, with no ill effects. With the risk of not adding much, it seems that Martin's example, which I repeat below, suggests a crossover between several "signatures" involved here - the signature of the generic, the signature of the method (the argument for setMethod()), and the signature of the function object

I defined an S4 class with a slot i. Then I wrote a regular function that attempted to increment i. This didn't work, apparently because of the general rule that a function can't change the values of its arguments outside the function. I gather there are ways around it, but the Green book admonishes "cheating on the S evaluation model is to be avoided" (p. 190). Thinking that

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

Full_Name: Ross Boylan Version: 2.10.0 OS: Windows XP Submission from: (NULL) (198.144.201.14) Some of the help for setGeneric seems to have been garbled. In the section "Basic Use", 5th paragraph (where the example counts as a single line 3rd paragraph) it says <quote> Note that calling 'setGeneric()' in this form is not strictly necessary before calling

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,

Writing R Extensions mentions that a package developer can provide a Makefile, but gives very little information about what should be in it. It says there must be a clean target, and later on there's mention of $(SHLIB): $(OBJECTS) $(SHLIB_LINK) -o $@ $(OBJECTS) $(ALL_LIBS) (in the F95 discussion). What should a Makefile provide, and what can it assume? In other words,