[Rd] environmentName

[Duncan Murdoch]

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
>>