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

[Byron Ellis]

It also wouldn't cover objects constructed by external functions (a
lot of my code produces these creatures).


On 9/21/06, Duncan Murdoch <murdoch at stats.uwo.ca> 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 at 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 at slot1 <- 1
>           obj at 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
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>


-- 
Byron Ellis (byron.ellis at gmail.com)
"Oook" -- The Librarian