On 30 Jan 2004 at 14:05, John Chambers wrote:
> 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.
Thank's for this clarification. I'll try to find another solution. Could you
comment on the "access" argument in "setClass()" ? From the
"setClass()" reference I can only guess what that might be:
"access: Access list for the class. Saved in the definition, but not
currently used."
Is this intended to implement an access control mechanism similar to
C++ like I stated in my previous message ? If that's the case I'll simply
provide access/assign methods for the slots that need validation. Once
access control is available I could hide those slots.
> 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.
I must admit that I didn't look into "Programming with Data", which I
don't have available right now, but I believe "S Programming" says the
same. I think the example code in the reference for "setValidity()" in R
is misleading here, especially the last four lines:
## Now we do something bad
[EMAIL PROTECTED] <- 1:20
## This should generate an error
## Not run: try(validObject(t1))
- Torsten
______________________________________________
[EMAIL PROTECTED] 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
