R devel - Aug 2009 - S4: names stripped during instantiation of grandchildren of numeric class

Dear All,

A small inconsistency (it's probably not even a buglet):

> setClass("A", contains="numeric")
[1] "A"
> names(new("A", c(a=23)))
[1] "a"
> setClass("B", contains="A")
[1] "B"
> names(new("B", c(a=23)))
NULL
>
This is exactly that kind of behavior S4 was invented for, you expect  
names to be there, but they are not :(.

If that behavior is left to be, one would have to implement @names  
manually for children of basic pseudo-classes, which is quite an overhead  
given the functionality is already in base R.

Thanks,
Vitalie.

Vitalie S. wrote:
>
> Dear All,
>
> A small inconsistency (it's probably not even a buglet):
>
>
>> setClass("A", contains="numeric")
> [1] "A"
>> names(new("A", c(a=23)))
> [1] "a"
>
>> setClass("B", contains="A")
> [1] "B"
>> names(new("B", c(a=23)))
> NULL
>>
>
> This is exactly that kind of behavior S4 was invented for, you expect 
> names to be there, but they are not :(.
You may expect them but you should not:  the  "names" attribute is not
a
slot of class "numeric".

If  you want names to be explicitly required, you have to say so:

 > setClass("A", contains = "numeric",
representation(names = "character"))
[1] "A"
 > names(new("A", c(a=23)))
[1] "a"
 > setClass("B", contains="A")
[1] "B"
 > names(new("B", c(a=23)))
[1] "a"

Having said all that, the treatment of "names" is very special and 
buried deep down in the implementation.  While simple treatment of names 
as a slot should work in most cases, it's unlikely that behavior will be 
100% as expected.

Also, the reason you sometimes got  names without specifying them as a 
slot is that the low-level code that assigns names (or other attributes) 
does not check that the S4 class definition has a corresponding slot.  
So the names in the non-S4 vector used as the data part are left in 
place, rather than say producing a warning or error.
>
> If that behavior is left to be, one would have to implement @names 
> manually for children of basic pseudo-classes, which is quite an 
> overhead given the functionality is already in base R.
>
> Thanks,
> Vitalie.
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>