Wow, thanks for the heads-up. That is horrible behavior. But using
baseenv() doesn't seem like the solution either. I'm new to proto,
but it seems like this is also a big drawback:
> z <- 1
> proto(baseenv(), expr={a=z})$a
Error in eval(expr, envir, enclos) : object "z" not found
--
Ben
----------------- Original message -----------------
From: Peter Danenberg <p...@roxygen.org>
To: r-devel@r-project.org
Date: Wed, 24 Feb 2010 22:38:54 -0600
I understand why the following happens ($.proto delegates to get,
which ascends the parent hierarchy up to globalenv()), but I still
find it anti-intuitive:
> z <- 1
> y <- proto(a=2)
> y$z
[1] 1
Although this is well-documented behavior; wouldn't it uphold the
principle of least surprise to inherit instead from baseenv() or
emptyenv()? (See attached patch.)
Spurious parent definitions have already been the source of bizarre
bugs, prompting me to use proto like this:
> z <- 1
> y <- proto(baseenv(), a=2)
> y$z
Error in get(x, env = this, inherits = inh) : object 'z' not found
It's cumbersome, but it ensures that parent definitions don't pollute
my object space; I would rather that be the default behaviour, though.
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
