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@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
