From ggrothendieck at gmail.com  Sun Jan  7 17:31:43 2007
From: ggrothendieck at gmail.com (Gabor Grothendieck)
Date: Sun, 7 Jan 2007 11:31:43 -0500
Subject: [Rd] environmentName
In-Reply-To: <45A11E85.60307@stats.uwo.ca>
References: <971536df0701070201n511119cfh6faae2b5828d445b@mail.gmail.com>
	<45A0D9C4.2090508@stats.uwo.ca>
	<971536df0701070701y58646fe8k28e4b3c7bb67f937@mail.gmail.com>
	<45A11E85.60307@stats.uwo.ca>
Message-ID: <971536df0701070831u704cfca9hda67a128b5a282f3@mail.gmail.com>

What I was referring to was your suggestion to add a class and a Name
attribute to the environment.  That would change all references to it.
But what I would really want to do is to leave it alone unchanged so it
can be used in its original form by other applications but for my purpose
create a subobject which does not modify the original object. The problem
is that attributes are always associated with the environment itself and
not the reference to it so in order to do this one would
have to create a wrapper list(env = e, Name = "My Name") which would not
inherit any of the environment methods since its not an environment but
instead I would have to replicate every environment method myself.


On 1/7/07, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
> On 1/7/2007 10:01 AM, Gabor Grothendieck wrote:
> > One other comment.  If I place an attribute on the environment as you
> > suggest that changes all uses of the environment.
>
> Yes, that's exactly what you wanted, as far as I can tell.  If an
> environment prints as
>
> <environment: 0x0181a320>
>
> then all uses of that environment will print the same way.
>
> Duncan Murdoch
>
> I cannot keep the
> > original environment intact and have a subobject which represents the
> > original environment plus the attribute.  This is just one example of why
> > the feature discussed in my wishlist is needed (i.e. the ability to have
> > the attributes attached to variables rather than to the environment itself).
> > The only way to handle this currently is with the list(env = ...) construct
> > and attach the name to that but that is a lot of overhead since its means
> > that the subobject is not an environment so all environment methods
> > need to be replicated rather than inherited/delegated from the superobject
> > which really ought to be properly supported.
> >
> > On 1/7/07, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
> >> On 1/7/2007 5:01 AM, Gabor Grothendieck wrote:
> >>> I noticed the new environmentName in R 2.5.0dev.  Thus I gather that
> >>> each environment has:
> >>>
> >>> (1) a name
> >>> (2) a hex value
> >>>
> >>> so
> >>>
> >>> 1. environmentName gets the name.  Is there any way to set the name?
> >> The NEWS entry says:
> >>
> >>     o  New function environmentName() to give the print name of
> >>        environments such as "namespace:base".
> >>        This is now used by str().
> >>
> >> Take a look at the implementation in src/main/builtin.c.  The name isn't
> >> part of the environment, this is just derived from how the environment
> >> is being used.
> >>
> >> If you want to attach a label to an environment, use an attribute.  You
> >> can put an S3 class on an environment if you want it to print your label
> >> by default rather than use the standard print mechanism.
> >>
> >>> 2. is there any way to get the hex value for an environment other than doing:
> >>>        e <- new.env()
> >>>        capture.output(e)
> >> Not in R code, but there's no use for it in R code, either.  If you want
> >> to test for whether two variables refer to the same environment, then
> >> attach a unique label to the environments when you create them and check
> >> the labels.
> >>
> >> Duncan Murdoch
> >>
>
>



[Rd] environmentName
Gabor Grothendieck