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. > >
Sounds reasonable. After some complicated replacements of slots at various levels, it would make sense to do a more complete test, and it does have to be done explicitly. It looks straightforward to have an argument complete= that defaults to FALSE; if so, I'll add it to r-devel. >Martin > >John Chambers <[EMAIL PROTECTED]> 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([EMAIL PROTECTED]) 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 ) [EMAIL PROTECTED] > 0 ) >>setClass("bar", >> representation( y="foo", z="numeric" ), >> validity = function( object ) [EMAIL PROTECTED] > 0 ) >>obj <- new( "bar", y = new( "foo", x=1 ), z = 1 ) >> >>and then... >> >> >> >> validObject( obj ) >> >> >> >> [1] TRUE >>## invalidate [EMAIL PROTECTED] >> >> >> [EMAIL PROTECTED]@x <- -1 >>validObject( [EMAIL PROTECTED] ) # right, this is not valid >> >> >> >> Error in validObject([EMAIL PROTECTED]) : invalid class "foo" object: >> FALSE >> >> >> ## [EMAIL PROTECTED] 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@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 > > > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
