Nicholas Van Weerdenburg wrote:

> I think immutability is usually a good thing from a design point of
> view, so I can see a general need to have more freezing options. When
> trying to extend old, bad Java code, I do some minor refactoring- 1.
> kill singletons, 2. make primary business objects immutable, and 3.
> add good logging (poor man's design-by-contract/testing). This makes
> the code understandable enough that some more aggressive refactoring
> can be done in the absense of a test suite, and well as enable some
> component level testing to be added, since it's now easier to seperate
> some of the concerns in the code (gui for application logic in a swing
> application, for instance). The point being the essential importance
> of immutability and being be able to control it from a contractual
> perspective.
> 
> And is there anyway to may attributes private so that subclasses can't
> see them? IIRC, this is  possible feature of Rite. This would remove
> some of the need, since immutability is enforced by invisibility.

Rite will do non-inherited instance variables via @_foo AFAIK. But I 
think this is only for avoiding name clashes, not for absolute security 
against modification. (Just think about .instance_eval and so on -- Ruby 
doesn't usually forbid you from doing bad things -- instead it tries to 
tell you that the thing is wrong and that you should think twice before 
using it.)

> Also, is there anything such as a deep freeze of an  object graph? I'm
> guessing not, since that would something hard to generalize easily (I
> think of all the Java serializatoin performance problems where it
> turned out that the data  was pulling the application code along with
> it).

I think this would only make sense when combined with a deep clone. It 
would be nice to have GC's object graph traversal functionality exposed. 
It is a good thing to have something like that available generally.

matz, are you listening?