odd assignInNamespace / setGeneric interaction

To clarify, I am going to fix the issue in the methods package
(actually I already have but need to test further). There's no intent
to change the behavior of q().
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

odd assignInNamespace / setGeneric interaction

Thread (5 messages)