Object validation and formal classes
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.
Torsten Steuernagel wrote:
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]]
______________________________________________ R-help at stat.math.ethz.ch mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html