Skip to content

as(1:4, "numeric") versus as.numeric(1:4, "numeric")

2 messages · Seth Falcon, John Chambers

Original
Seth Falcon
#
On 3/31/10 4:52 PM, John Chambers wrote:
To restate the issue (I think):

In a new R session if you happen to call:

   selectMethod("coerce", c("integer", "numeric"))

*Before* having made a call like as(1:4, "numeric") then there is a 
side-effect of creating definition "A" of the integer => numeric coerce 
method.  From this point forward all calls to as(x, "numeric") when x is 
"integer" will return as.numeric(x).

If instead you do not call selectMethod, then when calling as(x, 
"numeric") for x "integer" you get definition "B", the documented 
behavior, which simply returns x.

Presumably there are other similar cases where this will be an issue.

So while I agree this could be considered obscure, this qualifies as a 
bug in my book.  It seems desirable that selectMethod not change the 
state of the system in a user-visible fashion.  And calling 
selectMethod, or any other function, should not alter dispatch unless 
documented to do so.

I'm also suspicious of the behavior of the strict argument:

 > class(as(1:4, "numeric"))
[1] "integer"
 > class(as(1:4, "numeric", strict = TRUE))
[1] "integer"
 > class(as(1:4, "numeric", strict = FALSE))
[1] "integer"

Is that intended?

+ seth
John Chambers
#
On 4/1/10 9:45 AM, Seth Falcon wrote:
As I said in my reply to Herv?, if a change is proposed, I'd prefer it 
to be to disallow the selectMethod() call by not making coerce() a 
generic, or at least not one visible outside the namespace.

Your general stricture on selectMethod() sounds good, except that the 
function has the optional argument useInheritance=.  Then it will always 
be possible to have different side effects depending on how 
selectMethod() is called.  I would have no difficulty in principle with 
making the side-effects ONLY when it's called in the standard way, as 
happens implicitly from method dispatch.  To do that, however, requires 
making the change suggested in my previous paragraph, otherwise the user 
can  still frustrate the current implementation of as().
In the part of my mail you cut out, you'll see that this has to do with 
the semantics of
   class(from) <- "numeric"
I have no strong feelings on that, if someone wants to implement and 
defend a change.

John