R help - Jul 2002 - Suppressing "creating new generic" and "expanding the signature" messages

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?
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?

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

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

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