Skip to content

generic function argument list problem

5 messages · robin hankin, Martin Maechler, Jari Oksanen +1 more

Original
robin hankin
# 
Hi

it says in R-exts that


     A method must have all the arguments of the generic,  
including ... if the generic does.
     A method must have arguments in exactly the same order as the  
generic.
     A method should use the same defaults as the generic.


So, how come the arguments for rep() are (x, times, ...) and the  
arguments
for rep.default() are  (x, times, length.out, each, ...) ?  Shouldn't  
these be the same?


I am writing a rep() method for objects with class "octonion", and
my function rep.octonion() has argument list (x, times, length.out,  
each, ...)
just like rep.default(),   but  R CMD check complains about it, pointing
out that rep() and rep.octonion() have different arguments.

What do I have to do to my rep.octonion() function to make my package
  pass R CMD check without warning?


--
Robin Hankin
Uncertainty Analyst
National Oceanography Centre, Southampton
European Way, Southampton SO14 3ZH, UK
  tel  023-8059-7743
Martin Maechler
# 
Robin> Hi it says in R-exts that

    1) A method must have all the arguments of the generic,  
       including ... if the generic does.

    2) A method must have arguments in exactly the same order as the generic.

    3) A method should use the same defaults as the generic.


    Robin> So, how come the arguments for rep() are (x, times, ...) and the  
    Robin> arguments
    Robin> for rep.default() are  (x, times, length.out, each, ...) ?  Shouldn't  
    Robin> these be the same?

no.  If they should be the same, the "R-exts" manual would use
a much shorter formulation than the carefully crafted points
1--3 above!

The point is that methods often have  *extra* arguments
which match the "..." of the generic. 
That's one of the points about "..." !

Martin Maechler, ETH Zurich


    Robin> I am writing a rep() method for objects with class "octonion", and
    Robin> my function rep.octonion() has argument list (x, times, length.out,  
    Robin> each, ...)
    Robin> just like rep.default(),   but  R CMD check complains about it, pointing
    Robin> out that rep() and rep.octonion() have different arguments.

    Robin> What do I have to do to my rep.octonion() function to make my package
    Robin> pass R CMD check without warning?


    Robin> --
    Robin> Robin Hankin
    Robin> Uncertainty Analyst
    Robin> National Oceanography Centre, Southampton
    Robin> European Way, Southampton SO14 3ZH, UK
    Robin> tel  023-8059-7743

    Robin> ______________________________________________
    Robin> R-devel at r-project.org mailing list
    Robin> https://stat.ethz.ch/mailman/listinfo/r-devel



    Robin>      A method must have all the arguments of the
    Robin> generic, including ... if the generic does.  A method
    Robin> must have arguments in exactly the same order as the
    Robin> generic.  A method should use the same defaults as
    Robin> the generic.


    Robin> So, how come the arguments for rep() are (x, times,
    Robin> ...) and the arguments for rep.default() are (x,
    Robin> times, length.out, each, ...) ?  Shouldn't these be
    Robin> the same?


    Robin> I am writing a rep() method for objects with class
    Robin> "octonion", and my function rep.octonion() has
    Robin> argument list (x, times, length.out, each, ...)  just
    Robin> like rep.default(), but R CMD check complains about
    Robin> it, pointing out that rep() and rep.octonion() have
    Robin> different arguments.

    Robin> What do I have to do to my rep.octonion() function to
    Robin> make my package pass R CMD check without warning?


    Robin> -- Robin Hankin Uncertainty Analyst National
    Robin> Oceanography Centre, Southampton European Way,
    Robin> Southampton SO14 3ZH, UK tel 023-8059-7743

    Robin> ______________________________________________
    Robin> R-devel at r-project.org mailing list
    Robin> https://stat.ethz.ch/mailman/listinfo/r-devel
Martin Maechler
# 
................

    Robin> I am writing a rep() method for objects with class "octonion", and
    Robin> my function rep.octonion() has argument list (x, times, length.out,  
    Robin> each, ...)
    Robin> just like rep.default(),   but  R CMD check complains about it, pointing
    Robin> out that rep() and rep.octonion() have different arguments.

Hmm, not exactly, ``like rep.default'', I'm pretty sure.
Why not peek into R's <source>/src/library/base/man/rep.Rd  
which has

\usage{
rep(x, times, \dots)

\method{rep}{default}(x, times, length.out, each, \dots)
}

and definitely passes R CMD check without a warning.

    Robin> What do I have to do to my rep.octonion() function to make my package
    Robin> pass R CMD check without warning?
Jari Oksanen
#
On Wed, 2005-08-31 at 08:09 +0100, Robin Hankin wrote:
Shouldn't
pointing
I cannot repeat your problem. Probably you did something differently
than you said (like omitted "..." , misspelled times as time or
something else in your rep.octonion).

This is what I tried.

In R:
function (x, times, ...)
Creating directories ...
Creating DESCRIPTION ...
Creating READMEs ...
Saving functions and data ...
Making help files ...
Created file named './octonion/man/rep.octonion.Rd'.
Edit the file and move it to the appropriate directory.
Done.
Further steps are described in ./octonion/README

Then I edited octonion/man/rep.octonion.Rd so that it uses the generic
and passes R CMD check (virgin Rd files produced by package.skeleton
fail the test, which I found a bit weird). Here are the minimum changes
you need to pass the tests.

--- rep.octonion.Rd.orig        2005-08-31 10:56:36.000000000 +0300
+++ rep.octonion.Rd     2005-08-31 10:55:25.000000000 +0300
@@ -7,5 +7,5 @@
 }
 \usage{
-rep.octonion(x, times, length.out, each, ...)
+\method{rep}{octonion}(x, times, length.out, each, ...)
 }
 %- maybe also 'usage' for other objects documented here.
@@ -18,5 +18,5 @@
 }
 \details{
-  ~~ If necessary, more details than the __description__  above ~~
+  ~~ If necessary, more details than the description  above ~~
 }
 \value{
@@ -31,7 +31,7 @@
 \note{ ~~further notes~~ }

- ~Make other sections like Warning with \section{Warning }{....} ~

-\seealso{ ~~objects to See Also as \code{\link{~~fun~~}}, ~~~ }
+
+\seealso{ ~~objects to See Also as \code{\link{rep}}, ~~~ }
 \examples{
 ##---- Should be DIRECTLY executable !! ----
@@ -42,4 +42,4 @@
 function(x, time, length.out, each, ...) {}
 }
-\keyword{ ~kwd1 }% at least one, from doc/KEYWORDS
-\keyword{ ~kwd2 }% __ONLY ONE__ keyword per line
+\keyword{ models }% at least one, from doc/KEYWORDS
+

So this replaces rep.octonion with \method{rep}{octonion}, removes __
from description (these cause latex errors), remove a hanging top level
text "Make other sections...", and removes a link to non-existent
~~fun~~ (I'm not sure if adding a real keyword is necessary).

This passes tests. Including 

* checking S3 generic/method consistency ... OK

Conclusion: check your files. (It is pain: been there, done that.)

cheers, jari oksanen
Göran Broström
#
On Wed, Aug 31, 2005 at 09:30:37AM +0200, Martin Maechler wrote:
Martin, sorry if I am pedantic, but is 2. above that clear? Suppose that
the generic has arguments (a, b, ...). Then, if I want to add an argument
'X' to a method, the argument list (a, b, X, ...) for the method would be OK,
right? But how about (a, X, b, ...) or (a, b, ..., X)? I guess that would 
be wrong (but I haven't checked; is it maybe ok?!). 

The point is: What does it mean that two lists "have arguments in exactly 
the same order", when one list is a proper subset of the other? Maybe one 
should add "The common arguments, except ..., must have exactly the same 
_position_ in the generic and the method." 

G?ran