From hornik at ci.tuwien.ac.at  Mon Jun  9 09:37:35 2003
From: hornik at ci.tuwien.ac.at (Kurt Hornik)
Date: Mon Jun  9 12:37:04 2003
Subject: [Rd] R CMD check: is it error to setMethod for class not currently
	defined?
In-Reply-To: <5.2.0.9.1.20030607220218.00acc830@imaphost.wehi.edu.au>
References: <5.2.0.9.1.20030607220218.00acc830@imaphost.wehi.edu.au>
Message-ID: <16100.11055.839867.75803@mithrandir.hornik.net>

>>>>> Gordon Smyth writes:

> Should R CMD check consider it an error to define a new method using
> setMethod for a class which is not currently defined? It seems to me
> that it would be best not to consider this an error.

[R CMD check by itself definitely does not test for this.]

> What currently happens in that setMethod issues a warning, quite
> correctly.  This warning produces an object 'last.warning'. Then R CMD
> check issues a WARNING that 'last.warning' is an undocumented code
> object.

> Would it be a good idea to make R CMD check disregard the object
> 'last.warning' when checking for undocumented code objects? If people
> agree, I could try to make a patch for the R CMD check code.

Why should it?  Packages could have an object called last.warning in
their environment---the last.warning created by warning() seems to end
up in .GlobalEnv ...

What seems to happen is that you have a package installed as a save
image which at save time creates a warning and hence last.warning in
.GlobalEnv.  The way installing as a save image works everything in
.GlobalEnv gets included in the package environment.  If for some reason
this produces something 'unwanted', it can still be removed e.g. from
inside the package load hook(s) (e.g., your .First.lib()).  The QC
tools, when working on installed packages, simply load and attach them,
and perform computations on what is available then.

Best
-k


[Rd] R CMD check: is it error to setMethod for class not currently defined?
Kurt Hornik