On 4/1/10 9:45 AM, Seth Falcon wrote:
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.
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().
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?
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
+ seth
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
