> Martin Maechler
> on Fri, 16 Jun 2023 11:41:12 +0200 writes:
> Mikael Jagan
> on Thu, 15 Jun 2023 22:00:45 -0400 writes:
>> On 2023-06-15 5:25 pm, Hervé Pagès wrote:
>>> Oh but I see now that you've already tried this in your
>>> R/AllGenerics.R, sorry for
> Mikael Jagan
> on Thu, 15 Jun 2023 22:00:45 -0400 writes:
> On 2023-06-15 5:25 pm, Hervé Pagès wrote:
>> Oh but I see now that you've already tried this in your
>> R/AllGenerics.R, sorry for missing that,
yes, this one:
setGeneric("qr.X",
function(qr,
On 2023-06-15 5:25 pm, Hervé Pagès wrote:
Oh but I see now that you've already tried this in your R/AllGenerics.R,
sorry for missing that, but that you worry about the following message
being disruptive on CRAN:
The following object is masked from 'package:base':
qr.X
Why
Oh but I see now that you've already tried this in your R/AllGenerics.R,
sorry for missing that, but that you worry about the following message
being disruptive on CRAN:
The following object is masked from 'package:base':
qr.X
Why would that be? As long as you only define
I'd argue that at the root of the problem is that your qr.X() generic
dispatches on all its arguments, including the 'ncol' argument which I
think the dispatch mechanism needs to evaluate **before** dispatch can
actually happen.
So yes lazy evaluation is a real feature but it does not play
Thanks all - yes, I think that Simon's diagnosis ("user error") is correct:
in this situation one should define a reasonable generic function explicitly,
with a call to setGeneric, and not rely on the call inside of setMethod ...
But it is still not clear what the way forward should be (for
I agree that this is not an R issue, but rather user error of not defining a
proper generic so the check is right. Obviously, defining a generic with
implementation-specific ncol default makes no sense at all, it should only be
part of the method implementation. If one was to implement the same
On Sat, Jun 3, 2023 at 11:51 AM Mikael Jagan wrote:
> The formals of the newly generic 'qr.X' are inherited from the non-generic
> function in the base namespace. Notably, the inherited default value of
> formal argument 'ncol' relies on lazy evaluation:
>
> > formals(qr.X)[["ncol"]]
>
On Sat, 3 Jun 2023 11:50:59 -0400
Mikael Jagan wrote:
> > setOldClass("qr")
> > setMethod("qr.X", signature(qr = "qr"), function(qr, complete,
> > ncol) NULL)
>
> The formals of the newly generic 'qr.X' are inherited from the
> non-generic function in the base namespace.
Most of the errors, warnings and notes generated by R CMD check are
generated by code in the tools package, usually in the tools/R/QC.R
source file. Search that file for the error message, then backtrack to
find the code that causes it to be triggered.
If I recall correctly, it works on the
Thanks both. Yes, I was aware of globalVariables, etc. I guess I was hoping
to be pointed to the right place in the source code, in case the issue could
be addressed properly, notably as it seems to have already been addressed for
functions that are not S4 methods, i.e., codetools is apparently
The API supported workaround is to call globalVariables, which,
essentially, declares the variables without defining them (a distinction R
does not usually make).
The issue with this approach, of course, is that its a very blunt
instrument. It will cause false negatives if you accidentally use
Le 03/06/2023 à 17:50, Mikael Jagan a écrit :
In a package, I define a method for not-yet-generic function 'qr.X'
like so:
> setOldClass("qr")
> setMethod("qr.X", signature(qr = "qr"), function(qr, complete,
ncol) NULL)
The formals of the newly generic 'qr.X' are inherited from the
In a package, I define a method for not-yet-generic function 'qr.X' like so:
> setOldClass("qr")
> setMethod("qr.X", signature(qr = "qr"), function(qr, complete, ncol) NULL)
The formals of the newly generic 'qr.X' are inherited from the non-generic
function in the base namespace.
14 matches
Mail list logo
