I spoke too soon. dotsMethods will not work for me since it does not allow for
mixing of the ellipsis with other formal arguments. For example, the following
will not work if argument 'data' is not a formula; e.g. a data frame.
setGeneric("foo2", function(...) standardGeneric("foo2"))
setMethod("foo2", "formula",
function(..., data) list(...)
)
What is the recommended course of action if the validity of an R CMD check
warning is in doubt? In this case, the warning message indicates an
inconsistency that does not exist and references documentation that does not
seem to explain the actual issue.
-----Original Message-----
From: R-package-devel <r-package-devel-boun...@r-project.org> On Behalf Of
Smith, Brian J
Sent: Friday, January 17, 2020 11:45 AM
To: Joris Meys <joris.m...@ugent.be>; Duncan Murdoch
<murdoch.dun...@gmail.com>; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] [External] Re: S3 generic/method consistency warning
for formula method
Thanks for the tip about dotsMethods. I am mainly working with S4 objects in
my package, so that approach would fit well. The following S4 method seems to
work and pass R CMD checks.
setGeneric("foo2", function(...) standardGeneric("foo2"))
setMethod("foo2", "formula",
function(...) list(...)
)
In my actual implementation of S3 methods, I do check that all ... elements are
of the same class to avoid ending up in a world of hurt. Converting them to S4
methods will save me from having to do those checks - nice!
>From a language definition point of view though, I am still bothered that a
>check warning is triggered by the S3 formula method but not by others. That
>just seems inconsistent, and I have not yet seen any language documentation to
>explain the inconsistency. Are we sure this is not an issue with the R CMD
>check implementation?
Nevertheless, it looks like I have a way to get rid of the warning.
-----Original Message-----
From: Joris Meys <joris.m...@ugent.be>
Sent: Friday, January 17, 2020 10:12 AM
To: Smith, Brian J <brian-j-sm...@uiowa.edu>; Duncan Murdoch
<murdoch.dun...@gmail.com>; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] [External] Re: S3 generic/method consistency warning
for formula method
Hi Brian,
I get what you want to do, but S3 isn't suited for that at all. If all elements
in ... have to be the same class, you can use S4 (see ?dotsMethods). If not,
then using S3 makes even less sense. Take following example:
x <- list()
y <- c(1,2)
foo(x,y) will dispatch to foo.list()
foo(y,x) will dispatch to foo.character()
You'll be in a world of hurt if you want to maintain or update that code. If
you insist on using S3, you'll have to fix the position (and hence the name) of
the argument you want to dispatch on.
my 2 cents
Cheers
Joris
--
Joris Meys
Statistical consultant
Department of Data Analysis and Mathematical Modelling Ghent University Coupure
Links 653, B-9000 Gent (Belgium)
------------------------------
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
________________________________________
From: R-package-devel <r-package-devel-boun...@r-project.org> on behalf of
Smith, Brian J <brian-j-sm...@uiowa.edu>
Sent: Friday, January 17, 2020 4:59 PM
To: Duncan Murdoch; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] [External] Re: S3 generic/method consistency
warning for formula method
Thanks Duncan.
I was surprised too when first realizing this was possible. I believe the
reason it works is that UseMethod dispatches on the first supplied argument by
default. So, really the dispatch is on the first element of the ellipsis. The
'c' function works like this, albeit as a primitive function.
I would like to dispatch on the ellipsis to allow a user to name values being
passed in. Defining an initial x argument would indeed eliminate the warning,
but would not allow for user-naming of the value. I could have the user pass a
list of values to x and do dispatching manually, but that seems like more steps
for the user and more complication for the implementation than ought to be
necessary. There are other downsides to that approach in my particularly
application...
The issue mentioned below about calling the function with no arguments can be
solved by defining the following default method.
foo.default <- function(...) list(...)
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
