Skip to content
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

fix prepExtendedComment called from package::fun #229

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

pascal-sauer
Copy link
Contributor

No description provided.

@pascal-sauer pascal-sauer marked this pull request as ready for review November 11, 2024 14:47
@pascal-sauer
Copy link
Contributor Author

fixes #226

Comment on lines 24 to 33
functionCall <- as.character(cl[[1]])

# if readSource is called as madrat::readSource functionName will
# be in this unintuitive order c("::", "madrat", "readSource")
if (length(functionCall) == 3 && functionCall[[1]] == "::") {
f <- get(functionCall[[3]], envir = loadNamespace(functionCall[[2]]), mode = "function", sys.frame(-n - 1))
} else {
f <- get(functionCall, mode = "function", sys.frame(-n - 1))
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A bit unsafe to look for the function in some environment when functionCall[[2]] explicitly states it. But this is an internal function, so OK.
But why not

functionCall <- tail(as.character(cl[[1]]), 1)

?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A bit unsafe to look for the function in some environment when functionCall[[2]] explicitly states it

I assume you refer to the else branch? This is the behavior we had previously which I did not see a reason to change.

functionCall <- tail(as.character(cl[[1]]), 1)

I assume you suggest to skip the if else and use this instead to then call get(functionCall, mode = "function", sys.frame(-n - 1))? This won't work in a scenario where madrat::readSource is called, unless madrat is also attached (in which case readSource likely won't be called with the madrat:: prefix), because get would only look on the search path.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The pos argument can specify the environment in which to look for the object in any of several ways: as a positive integer (the position in the search list); as the character string name of an element in the search list; or as an environment (including using sys.frame to access the currently active function calls). The default of -1 indicates the current environment of the call to get. The envir argument is an alternative way to specify an environment.

https://rdrr.io/r/base/get.html

The fully qualified call is

f <- get(functionCall[[3]], 
         envir = loadNamespace(functionCall[[2]]),
         mode = "function",
         pos = sys.frame(-n - 1))

Now, which argument is used, envir or pos (as they point to different things)?

Spoiler: It is envir.

Since prepExtendedComment() is not exported, people calling it without attaching madrat are wholly responsible for their own pain ;).

But a safe formulation would be

f <- get(x = tail(functionCall, 1),
         envir = ifelse(1 == length(functionCall),
                        sys.frame(-n - 1),                # function() call
                        getNamespace(functionCall[[2]])), # pkg::function() call
         mode = "function")

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I assumed – wrongly – that pos would take precedence over envir and that get(…, sys.frame(-n - 1), inherits = TRUE) would just climb up the search path until some matching function is found.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found a way to get rid of this call stack inspection altogether

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants