[Rd] ... in generic/specific methods

[Paul Gilbert]

The prescription that "..." as an argument in a generic means that "..." should be an
argument in the specific methods (as is being suggested by checkMethods() in devel)
implies that errors will not automatically be generated when a specific method gets
arguments it does not use.  I do not view the change as an improvement since  I think
of these errors as a valuable mechanism for catching mistakes, so I would like to
understand the rationale. The change does not break things that work, it just means
that certain kinds of errors which were once caught automatically are no longer
caught automatically.

Now it is completely possible that this represents a fairly major misunderstanding of
inheritance on my part. But I believe my understanding is consistent with the
explanation of this in Chambers and Hastie (quoted below) which is the only place in
my somewhat dated collection of S reference books where I have found the issue
discussed at the necessary level of detail. My understanding is also consistent with
examples in MASS (at least the 1994 version) and elsewhere, whereas the prescription
of checkMethods() is not.  All of this is to say that there will be a number of long
time users who will be confused.

To the extent that I do understand the rationale of the checkMethods() prescription,
I believe the problem is that things are easier if UseMethod and NextMethod can pass
along arguments without needing to keep track of things. If specific methods use only
subsets of arguments the dispatch mechanism becomes more complicated or impossible.
Now, if it truly is impossible then the argument is fairly clear. But if it is only
more complicated then there is a trade-off between simplified dispatch and better
error checking (plus an enormous base of code which has assumed the prior mechanism).

Paul Gilbert
___
from J.M. Chambers and T.J. Hastie, "Statistical Models in S", 1992, Appendix A,
p466:

"When UseMethod() has found a method, it re-matches the actual call to the generic
with the definition of the method. Similarly, NextMethod() matches arguments with the
same order and names as the call to the generic. Methods do not need to have the same
arguments as the generic. In most examples, the method should allow optional, named
arguments to be passed down, if it plans to call NextMethod(). This means that most
such methods should have "..." as an argument. In the case of "[.factor"(), however,
we took the opposite approach. We decided that only one subscript argument made sense
for factors, although other objects might meaningfully have more arguments. The
definition here then produces a clean error message if an extra argument is included:

...
This is a tradeoff between allowing more general use of the method and providing
informative error messages; the relative importance of each should be examined
case-by-case."

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._