[Rd] validObject does not check validity of slots
Martin Morgan
mtmorgan at fhcrc.org
Tue Mar 7 17:50:03 CET 2006
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"
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
More information about the R-devel
mailing list