validObject does not check validity of slots

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

validObject does not check validity of slots

Martin Morgan
The documentation for validObject suggests that slots are checked for
validity, but validObject seems only to check that the slot has
something claiming to be correct; validObject(obj) does not perform
the equivalent of validObject(obj@y) for slot y.

This is also the second problem issue reported in

http://tolstoy.newcastle.edu.au/R/devel/05/03/0151.html

Relevant documentation, an example, and sessionInfo follow.

Martin

validObject             package:methods             R Documentation

Arguments:
     ...
     Note that validity methods do not have to check validity of any
     slots or superclasses:  the logic of 'validObject' ensures these
     tests are done once only.
     ...
Details:

     Validity testing takes place "bottom up":  first the validity of
     the object's slots, if any, is tested.  
     ...

setClass("foo",
         representation( x="numeric" ),
         validity = function( object ) object@x > 0 )
setClass("bar",
         representation( y="foo", z="numeric" ),
         validity = function( object ) object@z > 0 )
obj <- new( "bar", y = new( "foo", x=1 ), z = 1 )

and then...

> validObject( obj )
[1] TRUE
## invalidate obj@y
> obj@y@x <- -1
> validObject( obj@y )                  # right, this is not valid
Error in validObject(obj@y) : invalid class "foo" object: FALSE
> ## obj@y is invalid, but obj is valid?
> validObject( obj )                    # should be invalid?
[1] TRUE



> sessionInfo()
Version 2.3.0 Under development (unstable) (2006-03-03 r37471)
x86_64-unknown-linux-gnu

attached base packages:
[1] "methods"   "stats"     "graphics"  "grDevices" "utils"     "datasets"
[7] "base"

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: validObject does not check validity of slots

John Chambers-2
The problem is over-ambitious documentation.  Recursively running the
checks on slots for all validObject calls would be a fairly serious
efficiency hit.  Objects are checked for validity when created, other
than as the default object, so assuming the slot objects to be as
claimed is reasonable if they haven't been corrupted later on.  We'll
update the documentation.

Validity checking is a tricky business in general.  R validates new
objects, but users can turn valid objects into invalid objects in cases
where slots have to match in special ways (you can't apply validObject
each time a slot changes, since the change may be part of a bigger
computation that _will_ produce a valid object).  Similarly, constraints
on the elements can't be checked each time an element or subset of the
object changes, if the changes have to be done in stages.   Systems that
"commit" top-level assignments can check then, but R does not have that
distinction.

Martin Morgan wrote:

>The documentation for validObject suggests that slots are checked for
>validity, but validObject seems only to check that the slot has
>something claiming to be correct; validObject(obj) does not perform
>the equivalent of validObject(obj@y) for slot y.
>
>This is also the second problem issue reported in
>
>http://tolstoy.newcastle.edu.au/R/devel/05/03/0151.html
>
>Relevant documentation, an example, and sessionInfo follow.
>
>Martin
>
>validObject             package:methods             R Documentation
>
>Arguments:
>     ...
>     Note that validity methods do not have to check validity of any
>     slots or superclasses:  the logic of 'validObject' ensures these
>     tests are done once only.
>     ...
>Details:
>
>     Validity testing takes place "bottom up":  first the validity of
>     the object's slots, if any, is tested.  
>     ...
>
>setClass("foo",
>         representation( x="numeric" ),
>         validity = function( object ) object@x > 0 )
>setClass("bar",
>         representation( y="foo", z="numeric" ),
>         validity = function( object ) object@z > 0 )
>obj <- new( "bar", y = new( "foo", x=1 ), z = 1 )
>
>and then...
>
>  
>
>>validObject( obj )
>>    
>>
>[1] TRUE
>## invalidate obj@y
>  
>
>>obj@y@x <- -1
>>validObject( obj@y )                  # right, this is not valid
>>    
>>
>Error in validObject(obj@y) : invalid class "foo" object: FALSE
>  
>
>>## obj@y is invalid, but obj is valid?
>>validObject( obj )                    # should be invalid?
>>    
>>
>[1] TRUE
>
>
>
>  
>
>>sessionInfo()
>>    
>>
>Version 2.3.0 Under development (unstable) (2006-03-03 r37471)
>x86_64-unknown-linux-gnu
>
>attached base packages:
>[1] "methods"   "stats"     "graphics"  "grDevices" "utils"     "datasets"
>[7] "base"
>
>______________________________________________
>[hidden email] mailing list
>https://stat.ethz.ch/mailman/listinfo/r-devel
>
>  
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: validObject does not check validity of slots

Martin Morgan
Thanks John for the reply and explanation. I sometimes use validObject
interactively, and in those circumstances it might be nice to be able
to require recursive validity checking, e.g., with an optional
argument.

Martin

John Chambers <[hidden email]> writes:

> The problem is over-ambitious documentation.  Recursively running
> the checks on slots for all validObject calls would be a fairly
> serious efficiency hit.  Objects are checked for validity when
> created, other than as the default object, so assuming the slot
> objects to be as claimed is reasonable if they haven't been
> corrupted later on.  We'll update the documentation.
>
> Validity checking is a tricky business in general.  R validates new
> objects, but users can turn valid objects into invalid objects in
> cases where slots have to match in special ways (you can't apply
> validObject each time a slot changes, since the change may be part
> of a bigger computation that _will_ produce a valid object). 
> Similarly, constraints on the elements can't be checked each time an
> element or subset of the object changes, if the changes have to be
> done in stages.   Systems that "commit" top-level assignments can
> check then, but R does not have that distinction.
>
> Martin Morgan wrote:
>
>           The documentation for validObject suggests that slots are
> checked for validity, but validObject seems only to check that the
> slot has something claiming to be correct; validObject(obj) does not
> perform the equivalent of validObject(obj@y) for slot y.
>
> This is also the second problem issue reported in
>
> http://tolstoy.newcastle.edu.au/R/devel/05/03/0151.html
>
> Relevant documentation, an example, and sessionInfo follow.
>
> Martin
>
> validObject             package:methods             R Documentation
>
> Arguments:
>      ...
>      Note that validity methods do not have to check validity of any
>      slots or superclasses:  the logic of 'validObject' ensures these
>      tests are done once only.
>      ...
> Details:
>
>      Validity testing takes place "bottom up":  first the validity of
>      the object's slots, if any, is tested.  
>      ...
>
> setClass("foo",
>          representation( x="numeric" ),
>          validity = function( object ) object@x > 0 )
> setClass("bar",
>          representation( y="foo", z="numeric" ),
>          validity = function( object ) object@z > 0 )
> obj <- new( "bar", y = new( "foo", x=1 ), z = 1 )
>
> and then...
>
>  
>
>                     validObject( obj )
>    
>
>
>      [1] TRUE
> ## invalidate obj@y
>  
>
>                     obj@y@x <- -1
> validObject( obj@y )                  # right, this is not valid
>    
>
>
>      Error in validObject(obj@y) : invalid class "foo" object: FALSE
>  
>
>                     ## obj@y is invalid, but obj is valid?
> validObject( obj )                    # should be invalid?
>    
>
>
>      [1] TRUE
>
>
>
>  
>
>                     sessionInfo()
>    
>
>
>      Version 2.3.0 Under development (unstable) (2006-03-03 r37471)
> x86_64-unknown-linux-gnu
>
> attached base packages:
> [1] "methods"   "stats"     "graphics"  "grDevices" "utils"     "datasets"
> [7] "base"
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: validObject does not check validity of slots

John Chambers-2
Martin Morgan wrote:

>Thanks John for the reply and explanation. I sometimes use validObject
>interactively, and in those circumstances it might be nice to be able
>to require recursive validity checking, e.g., with an optional
>argument.
>  
>

Sounds reasonable.  After some complicated replacements of slots at
various levels, it would make sense to do a more complete test, and it
does have to be done explicitly.

It looks straightforward to have an argument complete= that defaults to
FALSE; if so, I'll add it to r-devel.

>Martin
>
>John Chambers <[hidden email]> writes:
>
>  
>
>>The problem is over-ambitious documentation.  Recursively running
>>the checks on slots for all validObject calls would be a fairly
>>serious efficiency hit.  Objects are checked for validity when
>>created, other than as the default object, so assuming the slot
>>objects to be as claimed is reasonable if they haven't been
>>corrupted later on.  We'll update the documentation.
>>
>>Validity checking is a tricky business in general.  R validates new
>>objects, but users can turn valid objects into invalid objects in
>>cases where slots have to match in special ways (you can't apply
>>validObject each time a slot changes, since the change may be part
>>of a bigger computation that _will_ produce a valid object).
>>Similarly, constraints on the elements can't be checked each time an
>>element or subset of the object changes, if the changes have to be
>>done in stages.   Systems that "commit" top-level assignments can
>>check then, but R does not have that distinction.
>>
>>Martin Morgan wrote:
>>
>>          The documentation for validObject suggests that slots are
>>checked for validity, but validObject seems only to check that the
>>slot has something claiming to be correct; validObject(obj) does not
>>perform the equivalent of validObject(obj@y) for slot y.
>>
>>This is also the second problem issue reported in
>>
>>http://tolstoy.newcastle.edu.au/R/devel/05/03/0151.html
>>
>>Relevant documentation, an example, and sessionInfo follow.
>>
>>Martin
>>
>>validObject             package:methods             R Documentation
>>
>>Arguments:
>>     ...
>>     Note that validity methods do not have to check validity of any
>>     slots or superclasses:  the logic of 'validObject' ensures these
>>     tests are done once only.
>>     ...
>>Details:
>>
>>     Validity testing takes place "bottom up":  first the validity of
>>     the object's slots, if any, is tested.  
>>     ...
>>
>>setClass("foo",
>>         representation( x="numeric" ),
>>         validity = function( object ) object@x > 0 )
>>setClass("bar",
>>         representation( y="foo", z="numeric" ),
>>         validity = function( object ) object@z > 0 )
>>obj <- new( "bar", y = new( "foo", x=1 ), z = 1 )
>>
>>and then...
>>
>>  
>>
>>                    validObject( obj )
>>    
>>
>>
>>     [1] TRUE
>>## invalidate obj@y
>>  
>>
>>                    obj@y@x <- -1
>>validObject( obj@y )                  # right, this is not valid
>>    
>>
>>
>>     Error in validObject(obj@y) : invalid class "foo" object: FALSE
>>  
>>
>>                    ## obj@y is invalid, but obj is valid?
>>validObject( obj )                    # should be invalid?
>>    
>>
>>
>>     [1] TRUE
>>
>>
>>
>>  
>>
>>                    sessionInfo()
>>    
>>
>>
>>     Version 2.3.0 Under development (unstable) (2006-03-03 r37471)
>>x86_64-unknown-linux-gnu
>>
>>attached base packages:
>>[1] "methods"   "stats"     "graphics"  "grDevices" "utils"     "datasets"
>>[7] "base"
>>
>>______________________________________________
>>[hidden email] mailing list
>>https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>>    
>>
>
>______________________________________________
>[hidden email] mailing list
>https://stat.ethz.ch/mailman/listinfo/r-devel
>
>  
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: validObject does not check validity of slots

Martin Maechler
>>>>> "JMC" == John Chambers <[hidden email]>
>>>>>     on Tue, 07 Mar 2006 16:33:59 -0500 writes:

    JMC> Martin Morgan wrote:
    >> Thanks John for the reply and explanation. I sometimes
    >> use validObject interactively, and in those circumstances
    >> it might be nice to be able to require recursive validity
    >> checking, e.g., with an optional argument.
    >>
    >>

    JMC> Sounds reasonable.  After some complicated replacements
    JMC> of slots at various levels, it would make sense to do a
    JMC> more complete test, and it does have to be done
    JMC> explicitly.

    JMC> It looks straightforward to have an argument complete=
    JMC> that defaults to FALSE; if so, I'll add it to r-devel.

I agree with the other Martin that this would be "nice" to have.
Also for debugging purposes, or as "watch point" when developing
new functionality.

Martin Maechler, ETH Zurich

    >> Martin
    >>
    >> John Chambers <[hidden email]> writes:
    >>
    >>
    >>
    >>> The problem is over-ambitious documentation.
    >>> Recursively running the checks on slots for all
    >>> validObject calls would be a fairly serious efficiency
    >>> hit.  Objects are checked for validity when created,
    >>> other than as the default object, so assuming the slot
    >>> objects to be as claimed is reasonable if they haven't
    >>> been corrupted later on.  We'll update the
    >>> documentation.
    >>>
    >>> Validity checking is a tricky business in general.  R
    >>> validates new objects, but users can turn valid objects
    >>> into invalid objects in cases where slots have to match
    >>> in special ways (you can't apply validObject each time a
    >>> slot changes, since the change may be part of a bigger
    >>> computation that _will_ produce a valid object).
    >>> Similarly, constraints on the elements can't be checked
    >>> each time an element or subset of the object changes, if
    >>> the changes have to be done in stages.  Systems that
    >>> "commit" top-level assignments can check then, but R
    >>> does not have that distinction.
    >>>
    >>> Martin Morgan wrote:
    >>>
    >>> The documentation for validObject suggests that slots
    >>> are checked for validity, but validObject seems only to
    >>> check that the slot has something claiming to be
    >>> correct; validObject(obj) does not perform the
    >>> equivalent of validObject(obj@y) for slot y.
    >>>
    >>> This is also the second problem issue reported in
    >>>
    >>> http://tolstoy.newcastle.edu.au/R/devel/05/03/0151.html
    >>>
    >>> Relevant documentation, an example, and sessionInfo
    >>> follow.
    >>>
    >>> Martin
    >>>
    >>> validObject package:methods R Documentation
    >>>
    >>> Arguments: ...  Note that validity methods do not have
    >>> to check validity of any slots or superclasses: the
    >>> logic of 'validObject' ensures these tests are done once
    >>> only.  ...  Details:
    >>>
    >>> Validity testing takes place "bottom up": first the
    >>> validity of the object's slots, if any, is tested.  ...
    >>>
    >>> setClass("foo", representation( x="numeric" ), validity
    >>> = function( object ) object@x > 0 ) setClass("bar",
    >>> representation( y="foo", z="numeric" ), validity =
    >>> function( object ) object@z > 0 ) obj <- new( "bar", y =
    >>> new( "foo", x=1 ), z = 1 )
    >>>
    >>> and then...
    >>>
    >>>
    >>>
    >>> validObject( obj )
    >>>
    >>>
    >>>
    >>> [1] TRUE ## invalidate obj@y
    >>>
    >>>
    >>> obj@y@x <- -1 validObject( obj@y ) # right, this is not
    >>> valid
    >>>
    >>>
    >>>
    >>> Error in validObject(obj@y) : invalid class "foo"
    >>> object: FALSE
    >>>
    >>>
    >>> ## obj@y is invalid, but obj is valid?  validObject( obj
    >>> ) # should be invalid?
    >>>
    >>>
    >>>
    >>> [1] TRUE
    >>>
    >>>
    >>>
    >>>
    >>>
    >>> sessionInfo()
    >>>
    >>>
    >>>
    >>> Version 2.3.0 Under development (unstable) (2006-03-03
    >>> r37471) x86_64-unknown-linux-gnu
    >>>
    >>> attached base packages: [1] "methods" "stats" "graphics"
    >>> "grDevices" "utils" "datasets" [7] "base"
    >>>
    >>> ______________________________________________
    >>> [hidden email] mailing list
    >>> https://stat.ethz.ch/mailman/listinfo/r-devel
    >>>
    >>>
    >>>
    >>>
    >>  ______________________________________________
    >> [hidden email] mailing list
    >> https://stat.ethz.ch/mailman/listinfo/r-devel
    >>
    >>
    >>

    JMC> [[alternative HTML version deleted]]

    JMC> ______________________________________________
    JMC> [hidden email] mailing list
    JMC> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel