[Rd] validity testing as part of '@<-'

[Martin Morgan]

While on the topic... validObject might check that the object (and its
slots) is actually the new S4:

> validObject(a)
[1] TRUE
> isS4(a)
[1] FALSE
> sessionInfo()
R version 2.4.0 beta (2006-09-22 r39490) 
x86_64-unknown-linux-gnu 

locale:
LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=en_US;LC_COLLATE=en_US;LC_MONETARY=en_US;LC_MESSAGES=en_US;LC_PAPER=en_US;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US;LC_IDENTIFICATION=C

attached base packages:
[1] "methods"   "stats"     "graphics"  "grDevices" "utils"     "datasets" 
[7] "base"     


Thomas Lumley <tlumley at u.washington.edu> writes:

> On Fri, 22 Sep 2006, Parlamis Franklin wrote:
>
>> all those points are good ones, i just wonder what happens to S4
>> "guarantees" when invalid objects are allowed to exist.  one of the
>> advantages of methods, as i understand, is that they can be written
>> with absolute confidence about what is being passed to them, and thus
>> do not need to contemplate a bunch of different possibilities (and as
>> a result can be terse and stylized). it seems if you really want
>> bulletproof code, you have to make validObject the first call in any
>> method definition to which an object with a validity method is being
>> passed (and which relies on receiving a valid object).  i am not sure
>> whether the time spent in those validObject calls is less than the
>> time that might be spent in enforcing validity checks on all possible
>> object mutations.
>
> I think the contract is that new() guarantees an object is valid, and that 
> programmers must guarantee that object mutation maintains validity. 
> validObject() is available as a tool to help programmers fulfill their 
> side of the bargain, but its use is not required. Given this contract it 
> is not necessary for methods to check that the objects they are given are 
> valid.
>
> Since validObject() isn't guaranteed to be true when changes are in 
> progress, it is not easy to identify a necessary and sufficient set of 
> places to call validObject() to ensure validity automatically.
>
> The other consequence of validObject() not being compulsory is that it can 
> be slow -- it can check properties that are expensive to verify but are 
> cheap to maintain. For example, you could have a data object where 
> validObject() did a lot of range checks and consistency checks between 
> variables.  Redoing these checks would be appropriate for a [<- method, 
> which changes the values, but not for a [ method that just extracts a 
> subset.
>
>  	-thomas
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Martin T. Morgan
Bioconductor / Computational Biology
http://bioconductor.org