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

[Thomas Lumley]

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