On 3/31/10 4:52 PM, John Chambers wrote:
The example is confusing and debatable, but not an obvious bug. And
your presentation of it is the cause of much of the confusion
(unintentionally I'm sure).
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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
