Object validation and formal classes

I'm using R 1.8.1 (Win32, Linux) and have some difficulties using 
validation functions for S4 classes. The problem is if I specify a 
validation function with setValidity("myclass", validate.myclass) object 
validation is only performed when I create an instance using 
new("myclass"), or when I explicitly call validObject(x) where x is of 
class "myclass", of course. 

According to the reference docs, I would expect that validation always 
takes place implicitly when I manipulate an object of "myclass". This 
especially includes implicit validation if I change slots directly, i.e. 
x at myslot <- 1:50 should call my validation function. Unfortunately, it 
isn't called and instead of raising an error and leaving the object 
unchanged in case validation fails, the object is always changed no 
matter what I assign to the slot.

I'm not sure if I'm missing something here or if I just didn't get the point 
of validation functions, but I believe there must be a way to assure that 
an object is in a consistent state.

Thanks for your help,

Torsten

On 29 Jan 2004 at 20:04, Robert Gentleman wrote:

 There are some efficiency issues that prevent constant checking (at
 least at the present time). There are also some other issues that
 need to be adequately addressed too. For example, suppose I had an
 object with two slots
  a - a character string 
  b - the number of characters

Yes, efficiency was also a concern I had with my original understanding 
of what the validation function is supposed to do. Reading the docs I 
got the impression that 

1) during an assignment the validation function will be called with a 
copy of the object that already has the new value assigned 

2) if it returns TRUE that copy is returned as the result of the assigment 

3) otherwise, an error is raised.

That would be pretty inefficient for large objects. What does actually 
happen when I call "slot<-" ? I suppose that this always operates on the 
object in sys.parent() of "slot<-" and never creates a copy of the 
specified object.
 

 and I set my validity checker to make sure that the length of the
 string is the number in b. Now that basically means that I can never
 change the string (except to other strings of the same length) if
 validity checking happened after every change. I somehow need
 changing both a and b to be instantaneous (which they currently are
 not). We have not really gone far enough down that path yet to know
 what the right thing is, but we  are working on it. So for now
 validity checking occurs at a   few specific points and if/when you
 ask for it. 

What about access control ? The docs state it isn't implemented yet. If 
there was something similar to C++ one could set critical slots to 
"private" and only allow access and assignment via (replacement) 
methods. At first sight, this seems feasible and shouldn't cost much 
performance.

Another approach might be an (optional) validation function for each 
individual slot or for groups of slots that doesn't need to validate the 
whole object but only changes that may occur in conjunction with a 
single slot or group of slots. Of course, efficiency issues are more likely 
to occur in this scenario. The "@<-" operator seems to call "slot<-" by 
default, maybe I can overload "slot<-" for my class and implement this 
kind of validation on my own ? I guess some tricks will be necessary 
here to prevent that "slot<-" is called recursively if the validation 
function for one slot attempts to make an assignemt to another slot.

So if I don't find a feasible solution in the meantime, the best way 
would be writing wrappers for those slots that need validation and tell 
the users to use those instead of changing the object directly ?

Thanks again,

Torsten


	[[alternative HTML version deleted]]

It was never the intention that validity checking happen automatically
on _every_ assignment of an object from the class--since those
assignments take place frequently during evaluation of functions, the
overhead would be unacceptable.  And as Robert points out, one needs
to postpone validity checking until a set of mutually dependent
changes is finished.

The "Programming with Data" description says that validity checking
takes place on "permanent assignment".  But this was not written with
R in mind, and the idea of permanent assignment is ambiguous in R.  It
could mean all assignments into the Global environment, or it could
mean on serializing (saving the workspace, e.g.).  If we agree on a
useful interpretation, automatic validity checking might be reasonable
in that sense in the future.