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

On 1/7/2007 11:31 AM, Gabor Grothendieck wrote:
> What I was referring to was your suggestion to add a class and a Name
> attribute to the environment.

Yes, that was clear.

Duncan Murdoch

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