Re: [Rd] does subset.data.frame need to accept extra arguments?
It needs to have ... in the formal argument list because the generic subset() does. It could enforce a run-time warning that some arguments were being skipped (by testing length(list(...)) for example), but then NextMethod might fail, in a case where an object has a complicated class vector. That wouldn't be a problem if the check was implemented in subset.data.frame, would it? Hadley -- Chief Scientist, RStudio http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] does subset.data.frame need to accept extra arguments?
On 13-07-11 12:59 PM, Hadley Wickham wrote: It needs to have ... in the formal argument list because the generic subset() does. It could enforce a run-time warning that some arguments were being skipped (by testing length(list(...)) for example), but then NextMethod might fail, in a case where an object has a complicated class vector. That wouldn't be a problem if the check was implemented in subset.data.frame, would it? Suppose the class vector is c(myclass, data.frame). Then subset.myclass would be called first if it existed. It might do some simple computation and then use NextMethod. It should not need to know that it is calling subset.data.frame next, so it will pass all of its arguments along, possibly including some that subset.data.frame should ignore. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] does subset.data.frame need to accept extra arguments?
On 13-07-07 11:09 PM, Peter Meilstrup wrote: The formal list for subset.data.frame accepts a ... args(subset.data.frame) function (x, subset, select, drop = FALSE, ...) NULL But it appears that subset.data.frame does not actually use the ... or pass it along: ... %in% all.names(body(subset.data.frame)) [1] FALSE Is there any reason why subset.data.frame needs to accept extra, unused arguments? One recurring error I see myself and other people making in interactive use is to type an = instead of an == in a subset call, e.g. subset(df, column=value) which I think ought to be an error, but it silently returns df instead. If ... were eliminated from the formals of subset.data.frame, it would eliminate a frequent user error. It needs to have ... in the formal argument list because the generic subset() does. It could enforce a run-time warning that some arguments were being skipped (by testing length(list(...)) for example), but then NextMethod might fail, in a case where an object has a complicated class vector. This is basically a limitation of the S3 class system. The S4 system can do much more careful checking. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] does subset.data.frame need to accept extra arguments?
The formal list for subset.data.frame accepts a ... args(subset.data.frame) function (x, subset, select, drop = FALSE, ...) NULL But it appears that subset.data.frame does not actually use the ... or pass it along: ... %in% all.names(body(subset.data.frame)) [1] FALSE Is there any reason why subset.data.frame needs to accept extra, unused arguments? One recurring error I see myself and other people making in interactive use is to type an = instead of an == in a subset call, e.g. subset(df, column=value) which I think ought to be an error, but it silently returns df instead. If ... were eliminated from the formals of subset.data.frame, it would eliminate a frequent user error. Peter [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
