[Rd] By default, `names<-` alters S4 objects

[Hervé Pagès]

On 11-05-16 09:36 AM, John Chambers wrote:
> You set up a names slot in a non-vector. Maybe that should be allowed,
> maybe not. But in any case I would not expect the names() primitive to
> find it, because your object has a non-vector type ("S4").

But the names<-() primitive *does* find it. So either names() and
names<-() should both find it, or they shouldn't. I mean, if you care
about consistency and predictability of course.

H.


> You could do
> a at names if you thought that made sense:
>
>
>  > setClass("A", representation(names="character"))
> [1] "A"
>  > a <- new("A")
>  > a at names <- "xx"
>  > a at names
> [1] "xx"
>  > names(a)
> NULL
>
>
> If you wanted something sensible, it's more like:
>
>  > setClass("B", representation(names = "character"), contains = "integer")
> [1] "B"
>  > b <- new("B", 1:5)
>  > names(b) <- letters[1:5]
>  > b
> An object of class "B"
> [1] 1 2 3 4 5
> Slot "names":
> [1] "a" "b" "c" "d" "e"
>
>  > names(b)
> [1] "a" "b" "c" "d" "e"
>
> This allows both the S4 and the primitive code to deal with a
> well-defined object.
>
> John
>
>
> On 5/15/11 3:02 PM, Hervé Pagès wrote:
>> On 11-05-15 11:33 AM, John Chambers wrote:
>>> This is basically a case of a user error that is not being caught:
>>
>> Sure!
>>
>> https://stat.ethz.ch/pipermail/r-devel/2009-March/052386.html
> ......
>
>>
>> Ah, that's interesting. I didn't know I could put a names slot in my
>> class. Last time I tried was at least 3 years ago and that was causing
>> problems (don't remember the exact details) so I ended up using NAMES
>> instead. Trying again with R-2.14:
>>
>> > setClass("A", representation(names="character"))
>>
>> > a <- new("A")
>>
>> > attributes(a)
>> $names
>> character(0)
>>
>> $class
>> [1] "A"
>> attr(,"package")
>> [1] ".GlobalEnv"
>>
>> > names(a)
>> NULL
>>
>> > names(a) <- "K"
>>
>> > attributes(a)
>> $names
>> [1] "K"
>>
>> $class
>> [1] "A"
>> attr(,"package")
>> [1] ".GlobalEnv"
>>
>> > names(a)
>> NULL
>>
>> Surprise! But that's another story...
>>
>>>
>>> The modification that would make sense would be to give you an error in
>>> the above code. Not a bad idea, but it's likely to generate more
>>> complaints in other contexts, particularly where people don't
>>> distinguish the "list" class from lists with names (the "namedList"
>>> class).
>>>
>>> A plausible strategy:
>>> 1. If the class has a vector data slot and no names slot, assign the
>>> names but with a warning.
>>>
>>> 2. Otherwise, throw an error.
>>>
>>> (I.e., I would prefer an error throughout, but discretion ....)
>>
>> Or, at a minimum (if no consensus can be reached about the above
>> strategy), not add a "names" attribute set to NULL. My original
>> post was more about keeping the internal representation of objects
>> "normalized", in general, so identical() is more likely to be
>> meaningful.
>>
>> Thanks,
>> H.
>>
>>>
>>> Comments?
>>>
>>> John
>>>
>>>
>>>>
>>>> Thanks,
>>>> H.
>>>>
>>>>
>>>
>>> ______________________________________________
>>> R-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>


-- 
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpages at fhcrc.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319