[Rd] understanding virtual classes and extensions thereof

[Parlamis Franklin]

thank you John, as always, for your thoughtful responses.  (i've been  
teaching my children to play chess, which probably isn't that  
different an experience ;)  one further comment and a related (maybe)  
bug report.

comment:

setClass("mom")
setClass("kid2", contains = c("mom", "VIRTUAL"))

will give 'kid2' a prototype of class 'S4', whereas

setClass("kid2")
setClassUnion("mom", "kid2")

will give it a 'NULL' prototype.  as i mentioned in the last message,  
i don't know if that matters on any level, but i instinctively prefer  
the 'NULL' prototype.

__

(maybe) bug report:

the existence of an extends relation in the class definition depends  
on the order of the setIs calls.  see code below.

setClass("A")
setClass("AA")
setClass("AAA")
setClass("AAAA")
setIs("AA", "A")
setIs("AAA", "AA")
setIs("AAAA", "AAA")
getClass("AAAA")  # works fine

setClass("B")
setClass("BB")
setClass("BBB")
setIs("BBB", "BB")
setClass("BBBB")
setIs("BBBB", "BBB")
setIs("BB", "B")
getClass("BBBB") # does not show extension of class 'B'
extends("BBBB", "B") # does not show extension of class 'B'
attr(completeExtends(getClass("BBBB")), "names") # there it is

please note that this behavior does not occur if i only go to depth 3  
on the virtual nesting.

i am working in the global environment, so perhaps this is an issue  
of recaching at some point.

franklin

On Oct 21, 2006, at 4:43 AM, John Chambers wrote:

> IMO, the recommended version is:
>
> setClass("kid2", contains = c("mom", "VIRTUAL"))
>
> because it's the clearest, using the representation argument only  
> for defining slots.  Better yet, if your virtual classes don't have  
> any slots defined, use setClassUnion() for "mom", with the other  
> classes members of the union.
>
> The other versions are mainly to be back-compatible, with  
> "Programming with Data" in particular.  They _should_ produce the  
> same result.
>
> As for:
>
> setClass("kid4", contains = "mom")
>
> this is currently a meaningless class: It's not virtual but it has  
> no meaningful prototype.  My preference would be a change that  
> makes this a virtual class, as the programmer probably intended  
> (maybe with a warning for now since it's technically a change in  
> the API).
>
>
> Parlamis Franklin wrote:
>> I am having some trouble creating a hierarchy of virtual classes   
>> (akin to the class structure in the 'Matrix' package).  I think  
>> they  arise from my not understanding the best way to specify  
>> virtual  subclasses of a virtual class.  please see questions  
>> below code.
>>
>> setClass("mom")
>>
>> setClass("kid1", representation("mom", "VIRTUAL"))
>> setClass("kid2", representation("VIRTUAL"), contains = "mom")
>> setClass("kid3"); setIs("kid3", "mom")
>>
>> (i) Are 'kid1' and 'kid2' equivalent?  I.e., is there any  
>> difference  between including a superclass as an unnamed argument  
>> in the  'representation' call and including it in the 'contains'  
>> argument?   If not, why does the 'contains' argument exist?
>>
>> (ii) What is the difference between 'kid1' and 'kid2', on the one   
>> hand, and 'kid3', on the other hand?  I see that 'kid1' and  
>> 'kid2'  have prototypes of class 'S4', while 'kid3' has a  
>> prototype of class  "NULL".  But I don't really understand the  
>> implications of that.  I  am using virtual classes mostly to  
>> economize on method writing.  Will  it matter on any level whether  
>> my virtual classes have NULL or S4  prototypes?
>>
>> On a related note, the behavior exhibited below also seems  
>> infelicitous
>>
>> setClass("kid4", contains = "mom")
>> new("kid4")  # error in the show method
>>
>> franklin parlamis
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>