That is how R works with free variables, e.g. z <- 1 f <- function() z f() # 1
so the current behavior seems consistent with the rest of R. Note that the example below could be done like this to avoid the error: > z <- 1 > proto(baseenv(), a = z)$a [1] 1 On Thu, Feb 25, 2010 at 12:33 AM, Ben <mi...@emerose.org> wrote: > 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 > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel