From: Florian Gross Date: 2004-12-08T04:47:31+09:00 Subject: Re: Freezing Variable Assignment 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?