From misc7 at emerose.org  Thu Feb 25 06:33:50 2010
From: misc7 at emerose.org (Ben)
Date: Wed, 24 Feb 2010 23:33:50 -0600
Subject: [Rd] proto and baseenv()
In-Reply-To: <20100225043854.GA26106@klutometis.wikitex.org>
References: <20100225043854.GA26106@klutometis.wikitex.org>
Message-ID: <20100224233350.4e3da5db.misc7@emerose.org>

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 <pcd at roxygen.org>
To: r-devel at 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 at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



[Rd] proto and baseenv()
Ben