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 e ort 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.
