[Rd] S4: inheritance of validity methods?
vitosmail at rambler.ru
Tue Aug 18 17:19:17 CEST 2009
On Tue, 18 Aug 2009 15:42:48 +0200, Martin Morgan <mtmorgan at fhcrc.org>
> "Vitalie S." <vitosmail at rambler.ru> writes:
>> Dear Developers,
>> In current implementation of validity method, objects are first
>> coerced to superclass (slots are striped). Thus, it is not possible
>> to write validity method which would perform some checks on children
>> Say, I want to check if number of slots in a class is equal to "n":
>> setClass("A", representation(a="numeric", n="integer"),
>> prototype=list(a=12, n=1L),
>> if(length(slotNames(object))!=object at n+1) paste("Number
>> of slots must be ", object at n)
>> else TRUE
>> setClass("B", representation(b="numeric"), contains="A",
>> prototype=list(a=12, b=14, n=2L))
>> new("B", a=11, b=33)
>> Error in validObject(.Object) :
>> invalid class "B" object: Number of slots must be 2
>> Error, because an object of class "A" is passed to validObject with
>> one slot "b" removed and n=2.
>> Is were a work around for this, or I am just doomed to write the same
>> validity method for each children class?
> I think you're doomed, but checking the number of slots in an instance
> seems like a very unusual validity method -- isn't this the job of the
> methods package, not your implementation of particular classes?
That was a toy example. In fact that I need is to ensure that some
specific slots have the same length. Names of these slots are kept in
separate slot (@atributes).
I think it's not an insane idea to require a predefined relationship to
hold between "future" children's slots.
To be honest, I find it hard to think of a compelling reason to convert
the object before testing the validity. What can possibly go wrong if
children slots are kept in place?
>> Many thanks,
More information about the R-devel