[Rd] odd assignInNamespace / setGeneric interaction

[William Dunlap]

The problem is not specific to redefining the q function, but to
the interaction of assignInNamespace and setGeneric.  The
latter requires, roughtly, that the environment of the function
being replaced by an S4 generic is (or is the descendent of)
the environment in which it lives.

E.g., the following demonstrates the problem

% R --quiet --vanilla
> assignInNamespace("plot", function(x, ...) stop("No plotting allowed!"),
getNamespace("graphics"))
> library(stats4)
Error: package or namespace load failed for ‘stats4’ in loadNamespace(name):
 there is no package called ‘.GlobalEnv’

and defining the bogus plot function in the graphics namespace avoids the
problem

% R --quiet --vanilla
>  assignInNamespace("plot", with(getNamespace("graphics"), function(x,
...) stop("No plotting allowed!")), getNamespace("graphics"))
> library(stats4)
>

I suppose poeple who use assignInNamespace get what they deserve.


Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Thu, Apr 19, 2018 at 2:33 AM, Martin Maechler <maechler at stat.math.ethz.ch
> wrote:

> >>>>> Michael Lawrence <lawrence.michael at gene.com>
> >>>>>     on Wed, 18 Apr 2018 14:16:37 -0700 writes:
>
>     > Hi Bill,
>     > Ideally, your coworker would just make an alias (or shortcut or
>     > whatever) for R that passed --no-save to R. I'll try to look into
> this
>     > though.
>
>     > Michael
>
> Yes, indeed!
>
> As some of you know, I've been using R (for ca 23 years now)
> almost only from ESS (Emacs Speaks Statistics).
>
> There, I've activated '--no-save' for ca 20 years or so,
> nowadays (since Emacs has adopted "custom") I have had this in
> my ~/.emacs  custom lines
>
>  '(inferior-R-args "--no-restore-history --no-save ")
>
> standalone (to paste into your own ~/.emacs ) :
>
> (custom-set-variables '(inferior-R-args "--no-restore-history --no-save "))
>
> --------
>
> The current fashionable IDE to R,
> Rstudio, also allows to set such switches by its GUI:
>
> Menu [Tools]
>   --> (bottom) entry [Global Options]
>     --> the first sidebar entry  [R General]:
>     Look for two lines mentioning "workspace" or ".RData" and
>     change to 'save never' ( == --no-save),
>     and nowadays I also recommend my students to not *read*
>     these, i.e., '--no-restore'
>
> ---
>
> @Michael: I'm not sure what you're considering.  I feel that in
>  general, there are already too many R startup tweaking
>  possibilities, notably via environment variables.
> [e.g., the current ways to pre-determine the active .libPaths() in R,
>  and the fact the R calls R again during 'R CMD check' etc,
>  sometimes drives me crazy when .libPaths() become incompatible
>  for too many reasons .... yes, I'm diverting: that's another story]
>
> If we'd want to allow using (yet  another!) environment variable
> here, I'd at least would  make sure they are not consulted when
> explicit --no-save or --vanilla, etc are used.
>
> Martin
>
>
>     > On Wed, Apr 18, 2018 at 1:38 PM, William Dunlap via R-devel
>     > <r-devel at r-project.org> wrote:
>     >> A coworker got tired of having to type 'yes' or 'no' after quitting
> R: he
>     >> never wanted to save the R workspace when quitting.  So he added
>     >> assignInNamespace lines to his .Rprofile file to replace base::q
> with
>     >> one that, by default, called the original with save="no"..
>     >>
>     >> utils::assignInNamespace(".qOrig", base::q, "base")
>     >> utils::assignInNamespace("q", function(save = "no", ...)
>     >> base:::.qOrig(save = save, ...), "base")
>     >>
>     >> This worked fine until he decide to load the distr package:
>     >>
>     >> > suppressPackageStartupMessages(library(distr))
>     >> Error: package or namespace load failed for ‘distr’ in
>     >> loadNamespace(name):
>     >> there is no package called ‘.GlobalEnv’
>     >>
>     >> distr calls setGeneric("q"), which indirectly causes the environment
>     >> of base::q, .GlobalEnv, to be loaded as a namespace, causing the
> error.
>     >> Giving his replacement q function the environment
> getNamespace("base")
>     >> avoids the problem.
>     >>
>     >> I can reproduce the problem by making a package that just calls
>     >> setGeneric("as.hexmode",...) and a NAMEPACE file with
>     >> exportMethods("as.hexmode").  If my .Rprofile puts a version of
> as.hexmode
>     >> with environment .GlobalEnv into the base namespace, then I get the
> same
>     >> error when trying to load the package.
>     >>
>     >> I suppose this is mostly a curiosity and unlikely to happen to most
> people
>     >> but it did confuse us for a while.
>     >>
>     >> Bill Dunlap
>     >> TIBCO Software
>     >> wdunlap tibco.com
>     >>
>     >> [[alternative HTML version deleted]]
>     >>
>     >> ______________________________________________
>     >> R-devel at r-project.org mailing list
>     >> https://stat.ethz.ch/mailman/listinfo/r-devel
>     >>
>
>     > ______________________________________________
>     > R-devel at r-project.org mailing list
>     > https://stat.ethz.ch/mailman/listinfo/r-devel
>

	[[alternative HTML version deleted]]