[R] Suppressing "creating new generic" and "expanding the signature" messages

[John Chambers]

"Yi, Derek" wrote:
> 
> Hi all,
> 
> I am building a R package which defines a class.  I have overloaded methods
> for this class using setMethod, and now, when I require my package, I get
> diagnostic messages.
> 
> setMethod("[", signature(x = "portfolio"),
>         function(x, i, j, ...) {
>                 # ...
>         })
> 
> > require(portfolio)
> Loading required package: portfolio
> [... loading other required packages ...]
> Creating a new generic function for "as.data.frame" on element 1 of the
> search path
> Expanding the signature to include omitted arguments in definition: drop =
> "missing"
> Creating a new generic function for "summary" on element 1 of the search
> path
> [1] TRUE
> 
> I realize that the messages tell me that the generic functions have been
> expanded to accommodate new objects, but is there any way to suppress them?

Yes, say explicitly that you want a generic version of the function:
R> library(methods)
R> setGeneric("as.data.frame")
[1] "as.data.frame"
R> 

The message is a gentle reminder, in case you thought the function was
already a generic.

> Also, I have been trying to overload the [] operators for my object, with
> limited success.  I have declared an as.data.frame function, and then have
> been trying to use [.data.frame on the coerced object.  Everything works,
> but I get the omitted arguments message.  My function "prototype" is above;
> is there any way to avoid this?

Yes.  Include all the arguments of the generic in the method, since you
do seem to want to handle the drop= argument.  

> 
> I guess my fundamental vagueness comes from my uncertainty as to how the
> "drop" argument can be handled, if I only want to pass arguments directly
> into [.data.frame.  I run into "missing" arguments problems:
> 
> > args("[.data.frame")
> function (x, i, j, drop = if (missing(i)) TRUE else length(cols) ==
>     1)
> NULL

Unfortunately, there are 3 different mechanisms getting mixed in here: 
formal methods, the "matrix-like" behavior of data frames, and the drop=
"feature" of [ on matrices.

If you really want to preserve the full semantics of [.data.frame, you
may need to handle the drop argument explicitly; e.g., 

R> setMethod("[", signature(x="portfolio"),
+ function(x, i, j, ... , drop)
+ { if(missing(drop))  ## something including: "[.data.frame"(thing, i,
j)
+ else  ## something including:  "[.data.frame"(thing, i, j, drop)
+ x
+ }
+ )

However, let me guess that you will be better off being a little
incompatible; namely, don't honor the drop argument in the "[" function.

The reason is that drop= (however neat it seemed way back when we
invented it) messes up the ability to handle the object returned from
"[", because now we don't know what class of object will be returned,
even when we know the class of the argument(s).

So, for example, if your portfolio class had a slot with a data frame in
it, you're asserting that that slot is ALWAYS a data frame.  But if
drop=TRUE, the result of "[" on the slot is no longer a data frame, and
you cannot legally assign it back to the slot.  

We don't usually want a slot to be sometimes one thing and sometimes
another (there are ways to do that too, but it's not as clean a way to
think of the new class).

To make your code deal consistently with object classes, you may find
it's better to always call [.data.frame with drop=FALSE.

John Chambers


> 
> Many thanks,
> Derek
> 
> > R.version
>          _
> platform sparc-sun-solaris2.6
> arch     sparc
> os       solaris2.6
> system   sparc, solaris2.6
> status
> major    1
> minor    5.1
> year     2002
> month    06
> day      17
> language R
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
> r-help 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-help-request at stat.math.ethz.ch
> _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

-- 
John M. Chambers                  jmc at bell-labs.com
Bell Labs, Lucent Technologies    office: (908)582-2681
700 Mountain Avenue, Room 2C-282  fax:    (908)582-3340
Murray Hill, NJ  07974            web: http://www.cs.bell-labs.com/~jmc
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help 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-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._