similar to: Support for as(x, "raw")

Or maybe the "right" concept is that "numeric" is a virtual class with 3 subclasses: "complex", "double", and "integer". Anyway it's probably too late for implementing the "right" concept so it doesn't really matter. Thanks Martin for offering to fix the as(1L, "numeric") bug. Very much appreciated. I guess that means

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

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 >> structures, which in practice just shape data without adding a lot of

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

Hi, In the situation below the note issued by the dispatch algo doesn't seem right: setClass("A", representation(stuff="complex")) setAs("ANY", "A", function(from) new("A", stuff=as.complex(from))) > as(6, "A") An object of class "A" Slot "stuff": [1] 6+0i > as(6L, "A")

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

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:

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

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

Here is an example: setGeneric("foo", function(x, y) standardGeneric("foo")) setMethod("foo", c("numeric", "ANY"), function(x, y) cat("I'm the foo#numeric#ANY method\n") ) Dispatch works as expected but selectMethod() fails to find the method: > foo(1, TRUE) I'm the foo#numeric#ANY method >

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 inheritance through explicit coercion is confusing. As far as I know, there are only

Hi, > class(as(1:4, "numeric")) [1] "integer" Surprising but an explanation could be that an integer vector being a particular case of numeric vector, this coercion has nothing to do because 1:4 is already numeric. And indeed: > is.numeric(1:4) [1] TRUE > is.numeric(as(1:4, "numeric")) [1] TRUE However, 'as(1:4,

Hi, Many S4 objects in Bioconductor support "combining" via a "c" method. A common use case is to combine a collection of S4 objects stored in a list with the following idiom: do.call("c", list_of_objects) For many users this doesn't return what they expect though, because their 'list_of_objects' is a named list and this seems to "break"

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

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)

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

Hi, Just ran across this: ??? foo <- function(x, ..., z=22) z ??? setMethod("foo", "character", function(x, y=-5, z=22) y) ??? # Creating a generic function from function ?foo? in the global environment Then: ??? foo("a") ??? # [1] 22 Should return -5, not 22. That's because the call to .local() used internally by the foo() method does not name

As I tried to say on Dec. 11, there are two levels of "fix": 1. The fix to the complaint in the OP's subject heading is to conform to the default third argument, strict=TRUE: as(1L, "numeric") == 1.0 This generates some incompatibilities, as for classes that extend "numeric". But still leaves class(1.0) "numeric" and typeof(1.0) "double".

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 between "structure" and "vector" via an "explicit

Hi, On 01/23/2015 07:01 AM, luke-tierney at uiowa.edu wrote: > On Thu, 22 Jan 2015, Michael Lawrence wrote: > >> On Thu, Jan 22, 2015 at 11:44 AM, <luke-tierney at uiowa.edu> wrote: >>> >>> For default methods there ought to be a way to create those so the >>> default method is computed at creation or load time and stored in an >>>