-
Notifications
You must be signed in to change notification settings - Fork 232
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle dynamic R6 methods #1246
Comments
utils::getSrcLocation
in extract_r6_methods
that supports functions defined elsewhere and/or rlang::new_function
@yogat3ch can you please start by providing a simple example of an R6 class that illustrates this problem? |
Hi @hadley,
Just throw the code above in a package and document it. The errors should look something like: |
Hi roxygen2 crew,
This is a feature request regarding integrating
roxygen2
support for more flexible R6 method definitions that allow for functions to be defined elsewhere or to be defined withrlang::new_function
.Right now
extract_r6_methods
relies onutils::getSrcLocation
which requires that the method be declared in full inside the R6 class. In most instances this works fine.However, there are instances where this breaks down.
An R6 method could be a function with many arguments or a lengthy default input for an argument that would otherwise create an extraordinarily verbose class definition that becomes difficult to navigate in the source editor.
Two methods exists for solving this:
rlang::new_function
that allows for a longpairlist
to be defined elsewhere and expanded with!!!
utils::getSrcLocation
insideextract_r6_methods
will return NULL if a method is defined in either of these ways, causing themap_int
in which it's embedded to give an obtuse error of this nature:Is it possible to locate the method using the appearance of it's name in the class definition instead?
The text was updated successfully, but these errors were encountered: