The documentation for validObject suggests that slots are checked for
validity, but validObject seems only to check that the slot has
something claiming to be correct; validObject(obj) does not perform
the equivalent of validObject(obj at y) for slot y.
This is also the second problem issue reported in
http://tolstoy.newcastle.edu.au/R/devel/05/03/0151.html
Relevant documentation, an example, and sessionInfo follow.
Martin
validObject package:methods R Documentation
Arguments:
...
Note that validity methods do not have to check validity of any
slots or superclasses: the logic of 'validObject' ensures these
tests are done once only.
...
Details:
Validity testing takes place "bottom up": first the validity of
the object's slots, if any, is tested.
...
setClass("foo",
representation( x="numeric" ),
validity = function( object ) object at x > 0 )
setClass("bar",
representation( y="foo", z="numeric" ),
validity = function( object ) object at z > 0 )
obj <- new( "bar", y = new( "foo", x=1 ), z = 1 )
and then...
validObject( obj )
[1] TRUE
## invalidate obj at y
obj at y@x <- -1
validObject( obj at y ) # right, this is not valid
Error in validObject(obj at y) : invalid class "foo" object: FALSE
## obj at y is invalid, but obj is valid?
validObject( obj ) # should be invalid?
[1] TRUE
sessionInfo()
Version 2.3.0 Under development (unstable) (2006-03-03 r37471)
x86_64-unknown-linux-gnu
attached base packages:
[1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
[7] "base"
Thanks John for the reply and explanation. I sometimes use validObject
interactively, and in those circumstances it might be nice to be able
to require recursive validity checking, e.g., with an optional
argument.
Martin
John Chambers <jmc at r-project.org> writes:
The problem is over-ambitious documentation.? Recursively running
the checks on slots for all validObject calls would be a fairly
serious efficiency hit.? Objects are checked for validity when
created, other than as the default object, so assuming the slot
objects to be as claimed is reasonable if they haven't been
corrupted later on.? We'll update the documentation.
Validity checking is a tricky business in general.? R validates new
objects, but users can turn valid objects into invalid objects in
cases where slots have to match in special ways (you can't apply
validObject each time a slot changes, since the change may be part
of a bigger computation that _will_ produce a valid object).?
Similarly, constraints on the elements can't be checked each time an
element or subset of the object changes, if the changes have to be
done in stages. ? Systems that "commit" top-level assignments can
check then, but R does not have that distinction.
Martin Morgan wrote:
The documentation for validObject suggests that slots are
checked for validity, but validObject seems only to check that the
slot has something claiming to be correct; validObject(obj) does not
perform the equivalent of validObject(obj at y) for slot y.
This is also the second problem issue reported in
http://tolstoy.newcastle.edu.au/R/devel/05/03/0151.html
Relevant documentation, an example, and sessionInfo follow.
Martin
validObject package:methods R Documentation
Arguments:
...
Note that validity methods do not have to check validity of any
slots or superclasses: the logic of 'validObject' ensures these
tests are done once only.
...
Details:
Validity testing takes place "bottom up": first the validity of
the object's slots, if any, is tested.
...
setClass("foo",
representation( x="numeric" ),
validity = function( object ) object at x > 0 )
setClass("bar",
representation( y="foo", z="numeric" ),
validity = function( object ) object at z > 0 )
obj <- new( "bar", y = new( "foo", x=1 ), z = 1 )
and then...
validObject( obj )
[1] TRUE
## invalidate obj at y
obj at y@x <- -1
validObject( obj at y ) # right, this is not valid
Error in validObject(obj at y) : invalid class "foo" object: FALSE
## obj at y is invalid, but obj is valid?
validObject( obj ) # should be invalid?
[1] TRUE
sessionInfo()
Version 2.3.0 Under development (unstable) (2006-03-03 r37471)
x86_64-unknown-linux-gnu
attached base packages:
[1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
[7] "base"
"JMC" == John Chambers <jmc at r-project.org>
on Tue, 07 Mar 2006 16:33:59 -0500 writes:
JMC> Martin Morgan wrote:
>> Thanks John for the reply and explanation. I sometimes
>> use validObject interactively, and in those circumstances
>> it might be nice to be able to require recursive validity
>> checking, e.g., with an optional argument.
>>
>>
JMC> Sounds reasonable. After some complicated replacements
JMC> of slots at various levels, it would make sense to do a
JMC> more complete test, and it does have to be done
JMC> explicitly.
JMC> It looks straightforward to have an argument complete=
JMC> that defaults to FALSE; if so, I'll add it to r-devel.
I agree with the other Martin that this would be "nice" to have.
Also for debugging purposes, or as "watch point" when developing
new functionality.
Martin Maechler, ETH Zurich
>> Martin
>>
>> John Chambers <jmc at r-project.org> writes:
>>
>>
>>
>>> The problem is over-ambitious documentation.
>>> Recursively running the checks on slots for all
>>> validObject calls would be a fairly serious efficiency
>>> hit. Objects are checked for validity when created,
>>> other than as the default object, so assuming the slot
>>> objects to be as claimed is reasonable if they haven't
>>> been corrupted later on. We'll update the
>>> documentation.
>>>
>>> Validity checking is a tricky business in general. R
>>> validates new objects, but users can turn valid objects
>>> into invalid objects in cases where slots have to match
>>> in special ways (you can't apply validObject each time a
>>> slot changes, since the change may be part of a bigger
>>> computation that _will_ produce a valid object).
>>> Similarly, constraints on the elements can't be checked
>>> each time an element or subset of the object changes, if
>>> the changes have to be done in stages. Systems that
>>> "commit" top-level assignments can check then, but R
>>> does not have that distinction.
>>>
>>> Martin Morgan wrote:
>>>
>>> The documentation for validObject suggests that slots
>>> are checked for validity, but validObject seems only to
>>> check that the slot has something claiming to be
>>> correct; validObject(obj) does not perform the
>>> equivalent of validObject(obj at y) for slot y.
>>>
>>> This is also the second problem issue reported in
>>>
>>> http://tolstoy.newcastle.edu.au/R/devel/05/03/0151.html
>>>
>>> Relevant documentation, an example, and sessionInfo
>>> follow.
>>>
>>> Martin
>>>
>>> validObject package:methods R Documentation
>>>
>>> Arguments: ... Note that validity methods do not have
>>> to check validity of any slots or superclasses: the
>>> logic of 'validObject' ensures these tests are done once
>>> only. ... Details:
>>>
>>> Validity testing takes place "bottom up": first the
>>> validity of the object's slots, if any, is tested. ...
>>>
>>> setClass("foo", representation( x="numeric" ), validity
>>> = function( object ) object at x > 0 ) setClass("bar",
>>> representation( y="foo", z="numeric" ), validity =
>>> function( object ) object at z > 0 ) obj <- new( "bar", y =
>>> new( "foo", x=1 ), z = 1 )
>>>
>>> and then...
>>>
>>>
>>>
>>> validObject( obj )
>>>
>>>
>>>
>>> [1] TRUE ## invalidate obj at y
>>>
>>>
>>> obj at y@x <- -1 validObject( obj at y ) # right, this is not
>>> valid
>>>
>>>
>>>
>>> Error in validObject(obj at y) : invalid class "foo"
>>> object: FALSE
>>>
>>>
>>> ## obj at y is invalid, but obj is valid? validObject( obj
>>> ) # should be invalid?
>>>
>>>
>>>
>>> [1] TRUE
>>>
>>>
>>>
>>>
>>>
>>> sessionInfo()
>>>
>>>
>>>
>>> Version 2.3.0 Under development (unstable) (2006-03-03
>>> r37471) x86_64-unknown-linux-gnu
>>>
>>> attached base packages: [1] "methods" "stats" "graphics"
>>> "grDevices" "utils" "datasets" [7] "base"
>>>
>>> ______________________________________________
>>> R-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>>
>>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>>
JMC> [[alternative HTML version deleted]]
JMC> ______________________________________________
JMC> R-devel at r-project.org mailing list
JMC> https://stat.ethz.ch/mailman/listinfo/r-devel