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]]


