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 <[EMAIL PROTECTED]> 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@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Martin T. Morgan Bioconductor / Computational Biology http://bioconductor.org ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
