It also wouldn't cover objects constructed by external functions (a lot of my code produces these creatures).
On 9/21/06, Duncan Murdoch <[EMAIL PROTECTED]> 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])) > > [EMAIL PROTECTED] <- 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( [EMAIL PROTECTED] <- 1 > [EMAIL PROTECTED] <- 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@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Byron Ellis ([EMAIL PROTECTED]) "Oook" -- The Librarian ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
