From maechler at stat.math.ethz.ch  Tue Mar  7 22:59:10 2006
From: maechler at stat.math.ethz.ch (Martin Maechler)
Date: Tue, 7 Mar 2006 22:59:10 +0100
Subject: [Rd] validObject does not check validity of slots
In-Reply-To: <440DFC47.9060501@r-project.org>
References: <6phk6b7zf22.fsf@gopher3.fhcrc.org>
	<440CDC8B.9080905@r-project.org>
	<6ph1wxeyzb8.fsf@gopher3.fhcrc.org>
	<440DFC47.9060501@r-project.org>
Message-ID: <17422.558.399660.933037@stat.math.ethz.ch>

>>>>> "JMC" == John Chambers <jmc at r-project.org>
>>>>>     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 <jmc at r-project.org> 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 at 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 at x > 0 ) setClass("bar",
    >>> representation( y="foo", z="numeric" ), validity =
    >>> function( object ) object at z > 0 ) obj <- new( "bar", y =
    >>> new( "foo", x=1 ), z = 1 )
    >>> 
    >>> and then...
    >>> 
    >>> 
    >>> 
    >>> validObject( obj )
    >>> 
    >>> 
    >>> 
    >>> [1] TRUE ## invalidate obj at y
    >>> 
    >>> 
    >>> obj at y@x <- -1 validObject( obj at y ) # right, this is not
    >>> valid
    >>> 
    >>> 
    >>> 
    >>> Error in validObject(obj at y) : invalid class "foo"
    >>> object: FALSE
    >>> 
    >>> 
    >>> ## obj at 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"
    >>> 
    >>> ______________________________________________
    >>> R-devel at r-project.org mailing list
    >>> https://stat.ethz.ch/mailman/listinfo/r-devel
    >>> 
    >>> 
    >>> 
    >>> 
    >>  ______________________________________________
    >> R-devel at r-project.org mailing list
    >> https://stat.ethz.ch/mailman/listinfo/r-devel
    >> 
    >> 
    >> 

    JMC> 	[[alternative HTML version deleted]]

    JMC> ______________________________________________
    JMC> R-devel at r-project.org mailing list
    JMC> https://stat.ethz.ch/mailman/listinfo/r-devel



[Rd] validObject does not check validity of slots
Martin Maechler