A study on immutability usage

Peter Alexander peter.alexander.au at gmail.com
Tue Oct 2 09:05:47 PDT 2012


On Monday, 1 October 2012 at 12:28:33 UTC, bearophile wrote:
>>Our results from 14 Java applications indicates that 72-82% of 
>>fields are stationary<
>
>>programmers are sometimes forced (or voluntarily choose) to 
>>initialise fields late (i.e. after the constructor has 
>>completed). This prevents such fields from being marked final 
>>even when they are designed to be immutable.<
>
> [snip]
>
>>The programmer intends that every Parent has a Child and 
>>vice-versa and, furthermore, that these do not change for the 
>>life of the program. He/she has marked the eld Parent.child as 
>>nal in an eort to enforce this. However, he/she is unable to 
>>mark the eld Child.parent as nal because one object must be 
>>constructed before the other.<

I have noticed this myself.

While the cyclic reference thing does cause this every now and 
then, I actually find that the main cause (in large programs) is 
the unavailability of the constructor arguments.

For example, you want to construct system X, which needs system 
Y, but system Y hasn't been constructed or initialised yet. In a 
small program, you just pull the construction of Y before X. In a 
large program, construction of these things is all indirect, 
through factories, driven by data files, which in turn is driven 
by some other system. The easiest thing to do is just to make the 
system Y reference mutable, and set it later when you know 
they're both around.

I also find that a lot of it is simply because it's easier to not 
type 'final' or 'const' :-)  Immutability by default would 
certainly make things interesting.



More information about the Digitalmars-d mailing list