[R-pkg-devel] NOTE about use of `:::`

Thank you both for the suggestions. I would prefer a clean stack trace in
case of errors as input errors are caught by this function and hence users
might very well see errors emitted from it. It seems more informative to me
if the error message would say "Error in .parse_args?" than "Error in
new.env(?". But since this solution was suggested by both of you it is
likely that CRAN too would demand this or a similar approach instead of
using `:::`. I know `:::` is expansive, but the computations that follow
are typically at least a few minutes so anything that takes less than a few
seconds won't be noticeable.

I also thought about using `...` before, but then the signature of the
user-facing functions would be incomplete and IDEs won't be able to provide
suggestions.

Thanks for the help!

-- David

On Wed, Dec 14, 2022 at 7:11 PM Simon Urbanek <simon.urbanek at r-project.org

wrote:

David,

why not

call[[1]] <- parse_args

The assignment is evaluated in your namespace so that makes sure the call
is that of your function. The only downside I see is that in a stack

trace

you'll see the definition instead of the name.
Or possibly

do.call(parse_args, as.list(call[-1]))

Cheers,
Simon

PS: Note that ::: is expensive - it probably doesn't matter here, but
would in repeatedly called functions.

On 15/12/2022, at 12:19 PM, David Kepplinger <

david.kepplinger at gmail.com>

wrote:

Dear List,

I am working on updating the pense package and refactored some of the
methods. I have several functions which take the same arguments, hence

I'm

sending all these arguments to an internal function, called

`parse_args()`.

Since I want to evaluate the arguments in the caller's environment, I'm
using the following code

 call <- match.call(expand.dots = TRUE)
 call[[1]] <- quote(pense:::parse_args)
 args <- eval.parent(call)

Of course, R CMD CHECK complains about the use of `:::`, as it's almost
never needed. I think the above usage would fall into that area of
"almost", but I'm not sure if (a) there's a better approach and (b) the
CRAN team would agree with me. I would have to test (b) by submitting

and

working with the CRAN team, but I wanted to ask the list first to see

if

I'm missing something obvious. I don't want to export the function
parse_args() as it's not useful for a user, and the use is truly

internal.

Thanks and all the best,
David

      [[alternative HTML version deleted]]

        [[alternative HTML version deleted]]