By default, `names<-` alters S4 objects

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").

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.