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

From: Parlamis Franklin <>
Date: Fri 22 Sep 2006 - 21:43:36 GMT

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.

at any rate, i am certainly one of the less experienced people on this mailing list, so i will not shake the tree too hard, because i probably don't appreciate the sacrifices that might be required. just thought i'd toss it out there.


On Sep 21, 2006, at 2:35 PM, Byron Ellis wrote:

> It also wouldn't cover objects constructed by external functions (a
> lot of my code produces these creatures).
> On 9/21/06, Duncan Murdoch <> wrote:
>> On 9/21/2006 5:29 PM, Parlamis Franklin wrote:
>> > 'methods' package feature request / discussion starter:
>> >
>> > perhaps a call to 'validObject' should occur at part of any slot
>> > replacement operation (and the operation not be carried out if it
>> > would invalidate the object)? this may prevent the need for
>> > prophylactic 'validObject' calls in other user-defined
>> functions. in
>> > the example below, the slot assignment occurs even though it
>> > invalidates the object. the 'show' method then fails somewhat deep
>> > in a subsequently-called coercion method.
>> >
>> > library(Matrix)
>> > test <- Matrix(1:4+0.1, nrow = 2, dimnames = list(letters[1:2],

>> > LETTERS[1:2]))
>> > test@Dimnames <- list(1:100)
>> > test
>> >
>> > direct slot access (without a validity check) seems an easily
>> > accessible loophole to S4 object "guarantees".
>> Often changing a single slot puts the object into a temporarily
>> invalid
>> state; others need to be changed consistently before it could pass
>> the
>> validity test.
>> Perhaps you could handle this case by wrapping all the calls in some
>> sort of wrapper, e.g.
>> atomic( {obj@slot1 <- 1
>> obj@slot2 <- 2 })
>> but requiring that would break tons of existing code, and turning on
>> validObject tests everywhere would slow things down a lot. Isn't it
>> easier to just sprinkle a few more validObject() calls into your
>> code?
>> Duncan Murdoch
>> ______________________________________________
>> mailing list
> --
> Byron Ellis (
> "Oook" -- The Librarian mailing list Received on Sat Sep 23 11:42:56 2006

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.1.8, at Sat 23 Sep 2006 - 05:30:08 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.