similar to: selectMethod() can fail to find methods in situations of multiple dispatch

Displaying 20 results from an estimated 8000 matches similar to: "selectMethod() can fail to find methods in situations of multiple dispatch"

2019 Mar 22
2
selectMethod() can fail to find methods in situations of multiple dispatch
Hi Michael, Thanks for looking into this. I suspect that truncation of ANY suffixes from method signatures is also the culprit behind the sudden breakage of aliases of the form \alias{foo,numeric-method} when a method without the ANY suffix in its signature gets added to the ecosystem. See my post about this to the Bioc-devel mailing list a couple of months ago:
2019 Mar 22
2
selectMethod() can fail to find methods in situations of multiple dispatch
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
2018 May 16
2
Dispatch mechanism seems to alter object before calling method on it
On 05/15/2018 09:13 PM, Michael Lawrence wrote: > My understanding is that array (or any other structure) does not > "simply" inherit from vector, because structures are not vectors in > the strictest sense. Basically, once a vector gains attributes, it is > a structure, not a vector. The methods package accommodates this by > defining an "is" relationship
2018 May 16
2
Dispatch mechanism seems to alter object before calling method on it
Hi, This was quite unexpected: setGeneric("foo", function(x) standardGeneric("foo")) setMethod("foo", "vector", identity) foo(matrix(1:12, ncol=3)) # [1] 1 2 3 4 5 6 7 8 9 10 11 12 foo(array(1:24, 4:2)) # [1] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 If I define a method for array objects,
2018 May 16
2
Dispatch mechanism seems to alter object before calling method on it
On 05/16/2018 10:22 AM, Michael Lawrence wrote: > Factors and data.frames are not structures, because they must have a > class attribute. Just call them "objects". They are higher level than > structures, which in practice just shape data without adding a lot of > semantics. Compare getClass("matrix") and getClass("factor"). > > I agree that
2012 Aug 03
1
Interaction between callNextMethod() and selectMethod()
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)
2018 May 16
1
Dispatch mechanism seems to alter object before calling method on it
On 05/16/2018 01:24 PM, Michael Lawrence wrote: > On Wed, May 16, 2018 at 12:23 PM, Herv? Pag?s <hpages at fredhutch.org> wrote: >> On 05/16/2018 10:22 AM, Michael Lawrence wrote: >>> >>> Factors and data.frames are not structures, because they must have a >>> class attribute. Just call them "objects". They are higher level than >>>
2019 Mar 22
0
selectMethod() can fail to find methods in situations of multiple dispatch
Agreed but I'm not sure we want users accessing documentation with those types of aliases. One option is the method?foo("numeric") syntax. On Thu, Mar 21, 2019 at 9:52 PM Pages, Herve <hpages at fredhutch.org> wrote: > 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
2019 Mar 22
0
selectMethod() can fail to find methods in situations of multiple dispatch
If we started over, I'd try to avoid this sort of complexity, but "ANY" truncation has been happening since at least 2003. > matchSignature(c("numeric", "ANY"), foo) x "numeric" So I'm not sure we want to mess with it. Michael On Thu, Mar 21, 2019 at 8:14 PM Pages, Herve <hpages at fredhutch.org> wrote: > Hi Michael, >
2019 Mar 19
0
selectMethod() can fail to find methods in situations of multiple dispatch
This is due to the intentional truncation of ANY suffixes from method signatures. I've hacked selectMethod() to be robust to that and will commit soon. Thanks for the report. Michael On Thu, Mar 14, 2019 at 9:32 AM Pages, Herve <hpages at fredhutch.org> wrote: > Here is an example: > > setGeneric("foo", function(x, y) standardGeneric("foo")) > >
2016 Mar 19
2
unary class union of an S3 class
On 03/19/2016 01:22 AM, Michael Lawrence wrote: > > > On Sat, Mar 19, 2016 at 12:10 AM, Herv? Pag?s <hpages at fredhutch.org > <mailto:hpages at fredhutch.org>> wrote: > > On 03/18/2016 03:28 PM, Michael Lawrence wrote: > > > On Fri, Mar 18, 2016 at 2:53 PM, Herv? Pag?s > <hpages at fredhutch.org <mailto:hpages at
2016 Mar 19
2
unary class union of an S3 class
On 03/18/2016 03:28 PM, Michael Lawrence wrote: > > On Fri, Mar 18, 2016 at 2:53 PM, Herv? Pag?s <hpages at fredhutch.org > <mailto:hpages at fredhutch.org>> wrote: > > Hi, > > Short story > ----------- > > setClassUnion("ArrayLike", "array") > > showClass("ArrayLike") # no slot > >
2016 Mar 18
2
unary class union of an S3 class
Hi, Short story ----------- setClassUnion("ArrayLike", "array") showClass("ArrayLike") # no slot setClass("MyArrayLikeConcreteSubclass", contains="ArrayLike", representation(stuff="ANY") ) showClass("MyArrayLikeConcreteSubclass") # 2 slots!! That doesn't seem right. Long story ----------
2017 Nov 29
2
binary form of is() contradicts its unary form
Hi Mehmet, On 11/29/2017 11:22 AM, Suzen, Mehmet wrote: > Hi Herve, > > I think you are confusing subclasses and classes. There is no > contradiction. `is` documentation > is very clear: > > `With one argument, returns all the super-classes of this object's class.` Yes that's indeed very clear. So if "list" is a super-class of "data.frame" (as
2015 Sep 29
3
making object.size() more meaningful on environments?
Hi, Currently object.size() is not very useful on environments as it always returns 56 bytes, no matter how big the environment is: env1 <- new.env() object.size(env1) # 56 bytes env2 <- new.env(hash=TRUE, size=75000000L) object.size(env2) # 56 bytes env3 <- list2env(list(a=runif(25000000), L=LETTERS)) object.size(env3) # 56 bytes This makes it pretty useless on
2018 Jan 30
2
as.list method for by Objects
by() does not always return a list. In Gabe's example, it returns an integer, thus it is coerced to a list. as.list() means that it should be a VECSXP, not necessarily with "list" in the class attribute. Michael On Tue, Jan 30, 2018 at 2:41 PM, Herv? Pag?s <hpages at fredhutch.org> wrote: > Hi Gabe, > > Interestingly the behavior of as.list() on by objects seem to
2017 May 03
2
stopifnot() does not stop at first non-TRUE argument
Not sure why the performance penalty of nonstandard evaluation would be more of a concern here than for something like switch(). If that can't/won't be fixed, what about fixing the man page so it's in sync with the current behavior? Thanks, H. On 05/03/2017 02:26 AM, peter dalgaard wrote: > The first line of stopifnot is > > n <- length(ll <- list(...)) > >
2017 Nov 29
2
binary form of is() contradicts its unary form
Hi, The unary forms of is() and extends() report that data.frame extends list, oldClass, and vector: > is(data.frame()) [1] "data.frame" "list" "oldClass" "vector" > extends("data.frame") [1] "data.frame" "list" "oldClass" "vector" However, the binary form of is()
2020 May 22
2
paste(character(0), collapse="", recycle0=FALSE) should be ""
I agree with Herve, processing collapse happens last so collapse=non-NULL always leads to a single character string being returned, the same as paste(collapse=""). See the altPaste function I posted yesterday. Bill Dunlap TIBCO Software wdunlap tibco.com On Fri, May 22, 2020 at 9:12 AM Herv? Pag?s <hpages at fredhutch.org> wrote: > I think that > >
2015 Sep 29
1
making object.size() more meaningful on environments?
Hi Gabe, On 09/29/2015 02:51 PM, Gabriel Becker wrote: > Herve, > > The problem then would be that for A a refClass whose fields take up N > bytes (in the sense that you mean), if we do > > B <- A > > A and B would look like the BOTH take up N bytes, for a total of 2N, > whereas AFAIK R would only be using ~ N + 2*56 bytes, right? Yes, but that's still a *much*