From ggrothendieck at myway.com  Fri Nov 26 01:45:18 2004
From: ggrothendieck at myway.com (Gabor Grothendieck)
Date: Fri Nov 26 01:45:32 2004
Subject: [Rd] str() resets class for environments
References: <4D99275E380CA94F998977EDACE548DC062517@extas2-hba.tas.csiro.au>
	<001c01c4d1ef$e1158790$01000001@hblaptop>
	<loom.20041125T194910-681@post.gmane.org>
	<x2pt21ab08.fsf@biostat.ku.dk>
Message-ID: <loom.20041126T014210-352@post.gmane.org>

Peter Dalgaard <p.dalgaard <at> biostat.ku.dk> writes:

: 
: Gabor Grothendieck <ggrothendieck <at> myway.com> writes:
: 
: > : I am curious though, do you not run into problems by setting and getting
: > : attributes on environment in 'mvbutils'? The example of John Chambers I
: > : re-posted, which shows that attributes can (will?) get "killed by 
operating
: > : on the [environment] object "locally" in a function", suggests that you
: > : will.
: > : 
: > 
: > The Chambers example simply shows what can happen now -- not what should
: > happen.  The real question is what should happen.    If all objects
: > can have classes and attributes and if environments are objects then
: > it follows that environments should be able to have classes and
: > attributes too.  If the language is to be made irregular in this
: > respect then there needs to be a very good reason and none has
: > been put forth, at least in this thread.
: 
: Environments are already irregular in that they are never duplicated
: (which is what causes these issues in the first place). External
: pointers have the same feature, and Luke Tierney has suggested that
: they perhaps should be wrapped in an object with more normal
: semantics. Perhaps we should consider doing likewise with
: environments? 

To me that would make sense in keeping the rules of the language
more consistent.  The mvbutils example suggests that it also has
uses in addition to regularity and additional ones may come to
light too.


[Rd] str() resets class for environments
Gabor Grothendieck