It seems that what we need is really ignoreLocalVariables() rather
than globalVariables() ... ?
On 4/24/21 4:56 PM, Bill Dunlap wrote:
Has there been any thought given to an alternative to globalVariables
that would flag certain arguments to certain functions as being
evaluated in a non-standard way. E.g.,
usesNSE(FUN="with.default", ARGUMENTS="expr")
usesNSE(FUN="lm", ARGUMENTS=c("weights","subset","offset"))
usesNSE(FUN="~") # missing ARGUMENTS means all args are NSE
This information would be stored in the environment that contains FUN.
-Bill
On Sat, Apr 24, 2021 at 6:18 AM Martin Maechler
<maech...@stat.math.ethz.ch <mailto:maech...@stat.math.ethz.ch>> wrote:
>>>>> Ben Bolker
>>>>> on Thu, 22 Apr 2021 17:27:49 -0400 writes:
> For some reason that I don't remember, an R core member once
told me
> that they prefer x <- y <- NULL to
utils::globalVariables(c("x","y")) -
That could have been me. Even though I think I still have some
globalVariables() statements in some of my package sources, I've
decided that it *harms* really, notably for relatively common
variable names such
as "x": It declares them "global"
{ for the purpose of codetools::globalVariables() } everywhere,
i.e. for all functions in the package namespace and that
basically kills the reliability of globalVariables() checking
for the whole package.
> although I have also encountered problems with that strategy
in edge cases.
well, when?
Honestly, I don't remember. Something with order of evaluation and
the fact that a variable existed and was set to NULL in the package
namespace screwing things up.
> Here's an example from StackOverflow from today where for
some reason
> I don't understand, evaluation of function arguments
interacts with
> non-standard/lazy evaluation within a dplyr function such
that 'foo'
> works while 'x$foo' doesn't ... don't know if it's a similar
case.
>
https://stackoverflow.com/questions/67218258/getting-error-error-in-usemethodfilter-no-applicable-method-for-filter/67220198#67220198
<https://stackoverflow.com/questions/67218258/getting-error-error-in-usemethodfilter-no-applicable-method-for-filter/67220198#67220198>
{ ceterum censeo ... to use NSE (non-standard-evaluation) for
user convenience and to call this (together with really good
ideas) "tidy" has been one of the biggest euphemisms in the
history of
statistical computing ... but yes, that's just my personal opinon }
> On 4/22/21 5:19 PM, Kevin R. Coombes wrote:
>> Thanks.
>>
>> Obviously, long. long ago, (in a galaxy not far enough
away), Paul's
>> suggestion of using "aes_string" was the correct one, since
"aes" uses
>> non-standard evaluation. (And to quote somebody from an R
fortune
>> cookie, "The problem with non-standard evaluation is that it is
>> non-standard.") But teh documentation at the end oft he link
provided by
>> Robert explivityl tells you not to do that, since "aes_string is
>> deprecated". And reading more carefully into the manual
page for
>> aes_string, one does indeed find the statement that the
function is
>> "soft deprecated". I'm not sure what that means, other than
someone on
>> the development team doesn't like it.
>>
>> Instead, the vignette says you should
>> importFrom("rlang", ".data")
>> in your NAMESPACE, and write
>> ggplot(myData, aes(x = .data$myX, y = .data$myY))
>>
>> And now my dinosaur question: That looks like using one
non-standard
>> hack to cover up the problems with another non-standard
hack. Why the
>> heck is that any better for the developer than writing
>> ggplot(myData, aes(x = myData$myX, y = myData$myY))
>>
>> or using Dirk Eddelbuettel's suggestion of calling
utils::globalVariables ??
>>
>> It's time to tell those kids to get off of my lawn.
>> Kevin
>>
>> On 4/22/2021 4:45 PM, Robert M. Flight wrote:
>>> Kevin,
>>>
>>> This vignette from ggplot2 itself gives the "officially
recommended"
>>> ways to avoid the warnings from R CMD check
>>>
>>>
https://ggplot2.tidyverse.org/articles/ggplot2-in-packages.html
<https://ggplot2.tidyverse.org/articles/ggplot2-in-packages.html>
>>>
<https://ggplot2.tidyverse.org/articles/ggplot2-in-packages.html
<https://ggplot2.tidyverse.org/articles/ggplot2-in-packages.html>>
>>>
>>> Cheers,
>>>
>>> -Robert
>>>
>>> On Thu, Apr 22, 2021 at 4:39 PM Paul SAVARY
>>> <paul.sav...@univ-fcomte.fr
<mailto:paul.sav...@univ-fcomte.fr>
<mailto:paul.sav...@univ-fcomte.fr
<mailto:paul.sav...@univ-fcomte.fr>>> wrote:
>>>
>>> Hi Kevin,
>>>
>>> I was faced to the same problem and I used 'aes_string()'
instead
>>> of 'aes()'. You can then just write the name of the columns
>>> containing the data to plot as character strings.
>>>
>>> Example:
>>>
>>> myPlot <- function(myData, ...) {
>>> # get ready
>>> ggplot(myData, aes_string(x = "myX", y = "myY")) +
>>> # add my decorations
>>> theme_bw()
>>> }
>>>
>>> It is probably already the case for your function but you
need to
>>> include #' @import ggplot2 in your function preamble (if I
am not
>>> wrong).
>>>
>>> Kind regards
>>> Paul
>>>
>>> ----- Mail original -----
>>> De: "Kevin R. Coombes" <kevin.r.coom...@gmail.com
<mailto:kevin.r.coom...@gmail.com>
>>> <mailto:kevin.r.coom...@gmail.com
<mailto:kevin.r.coom...@gmail.com>>>
>>> À: "r-package-devel" <r-package-devel@r-project.org
<mailto:r-package-devel@r-project.org>
>>> <mailto:r-package-devel@r-project.org
<mailto:r-package-devel@r-project.org>>>
>>> Envoyé: Jeudi 22 Avril 2021 22:28:55
>>> Objet: [R-pkg-devel] Using ggplot2 within another package
>>>
>>> Hi,
>>>
>>> I'm trying to help clean up an R package for someone else to
>>> submit to
>>> CRAN. He has used ggplot2 to implement a plotting function
for the
>>> kinds
>>> of things that his packages generates. His plotting routine
basically
>>> looks like (after changing names to protect the innocent):
>>>
>>> myPlot <- fucntion(myData, ...) {
>>> # get ready
>>> ggplot(myData, aes(x = myX, y = myY)) +
>>> # add my decorations
>>> theme_bw()
>>> }
>>>
>>> Of course, "R CMD check --as-cran" complains that there is
no global
>>> binding for "myX" or "myY" since they are columns defined
in the
>>> data.frame "myData".
>>>
>>> What is the best way to work around this issue?
>>>
>>> Of course, dinosaurs like myself might be tempted to
suggest just
>>> using
>>> plain old "plot", so I don't need to see those suggestions.
>>>
>>> Do I just ignore the usual ggplot conventions and write
"myData$myX"
>>> inside "aes" in order to appease the CRAN checker? Or is
there some
>>> tidy-er way to solve this problem?
>>>
>>> Thanks,
>>> Kevin
>>>
>>> ______________________________________________
>>> R-package-devel@r-project.org
<mailto:R-package-devel@r-project.org>
>>> <mailto:R-package-devel@r-project.org
<mailto:R-package-devel@r-project.org>> mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
<https://stat.ethz.ch/mailman/listinfo/r-package-devel>
>>> <https://stat.ethz.ch/mailman/listinfo/r-package-devel
<https://stat.ethz.ch/mailman/listinfo/r-package-devel>>
>>>
>>> ______________________________________________
>>> R-package-devel@r-project.org
<mailto:R-package-devel@r-project.org>
>>> <mailto:R-package-devel@r-project.org
<mailto:R-package-devel@r-project.org>> mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
<https://stat.ethz.ch/mailman/listinfo/r-package-devel>
>>> <https://stat.ethz.ch/mailman/listinfo/r-package-devel
<https://stat.ethz.ch/mailman/listinfo/r-package-devel>>
>>>
>>
>>
>> [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-package-devel@r-project.org
<mailto:R-package-devel@r-project.org> mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
<https://stat.ethz.ch/mailman/listinfo/r-package-devel>
>>
> ______________________________________________
> R-package-devel@r-project.org
<mailto:R-package-devel@r-project.org> mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
<https://stat.ethz.ch/mailman/listinfo/r-package-devel>
______________________________________________
R-package-devel@r-project.org <mailto:R-package-devel@r-project.org>
mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
<https://stat.ethz.ch/mailman/listinfo/r-package-devel>
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
