Skip to content

Attributes of top level environments clobbered (was Re: [R] possible bug in function 'var' in R 2.7.2?)

1 message · Gabor Grothendieck

Original
Gabor Grothendieck
#
On Sat, Oct 4, 2008 at 10:45 AM, laurent <lgautier at gmail.com> wrote:
Some specifics need to be added to the "poor reliability" phrase relating to
of attributed environments.  The proto package changes the class attribute
of environments (but no other attribute of environments) and proto in turn
underlies large widely used packages which likely exercise it thoroughly yet
through this experience the only places where this was noticeable were
points #1 and #3 of the Avoiding R Bugs section of the proto home page
at http://r-proto.googlecode.com

Neither of these are two points are deal breakers as

- #1 has an easy workaround (just change one line in your DESCRIPTION file) and
  if the promised fix is made even this won't be necesary,

- #3 mostly seems mostly harmless in the context of proto as the only attribute
  change is from a class of  "enviornment" to c("proto",
"environment").  Artificial
  examples can be constructed where this is a problem but substantial experience
  with it suggests that it is not a problem in practice.

(The remaining R problems listed are all related to promises, not environments.)
Actually, I see the main benefit of this or other approach as
providing the missing
elements of S3 support to environments thereby potentially streamlining the
implementation of every package that needs it (proto, tcltk, R.oo, ...) or more
perhaps more accurately allowing tcltk and R.oo and other such packages to
become as streamlined as proto already is.

Each of these packages could then use inheritance rather than
containment thereby
leveraging the S3 OO facilities that one really expects R to provide.

It would be important that the new class whose objects contain environments is
sufficiently indistinguishable in terms of its methods from regular
environments so that
inheritance works transparently.

I assume that if e is a new style environment then parent.env(e) can be an
old style or new style environment and in a sense all the new style
environments can be regarded as childen of the old style environment they
contain.  There is some question of what happens if parent.env(e) is deleted
in the case that its a new style environment but its contained old style
environment is not deleted.   Is it left undefined or does it revert to the
old style environment?  Implementation and performance considerations
may suggest how best to handle this.

Using these three packages as example cases may help clarify the desired
functionality here.

Another possible approach would be to only have new style environments
rather than both or possibly only expose new style environments to the user
even if both existed.  Some thought would be required to determine which
was the most desirable.