From: Austin Ziegler Date: 2004-12-12T06:14:24+09:00 Subject: Re: Freezing Variable Assignment On Sun, 12 Dec 2004 02:02:24 +0900, itsme213 wrote: >>> And that would be quite reasonable. But my build up to that is: >>> what you consider virtual object state is specific to your >>> intent, and is derived ultimately from slots, as follows: >> Well... but you're now using this concept of 'slots' uncritically >> in connection with Ruby objects, whereas this all began with my >> suggesting that the term wasn't really suited. > That's because it would be repetitive to say "instance variable, > array index, hash key or value reference, or some C-accessible > data (like that underlying Class#superclass)" in each place I used > 'slot'. And state does not work because state is some aggregation > of instance variables or array indices or hash keys or value > references i.e. some aggregation of slots, and this discussion > needs to refer to _each element_ of that aggregation. Why? Except for meta-programming, it is not generally the case that all of this is necessary, and that's where I've objected to your propositions most of all. I understand that you believe that freeze should freeze the object and everything it contains, but I don't agree -- and I suspect *most* folks who use Ruby don't either. Your custom freeze code appears to be a reasonable way around the issue at that. > The fact that Ruby is very dynamic e.g. can add instance variables > on the fly, delegate, etc. does not change this. It just means we > need to make some distinctions, which we would need to be aware of > in any case! e.g. We must know if x.freeze_all_instance_variables > (or all array indices, or hash ...) means (a) prohibit change to > all currently defined ivars of x, or (b) prohibit change to all > actual and potential ivars of x x.freeze means (b), because new instance variables can't be added after an object is frozen. >> I don't necessarily consider the object to have a virtual state. > But I believe that _is_ what is intended by "freeze", and I think > others comments in this thread bear that out. I get just the opposite, except from you. -austin -- Austin Ziegler * halostatue@gmail.com * Alternate: austin@halostatue.ca