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