I am back.
This study regards how "final" is used in Java programs, and
generally how immutability is used and is useful:
http://whiley.org/2012/09/30/profiling-field-initialisation-in-java/
Slides:
http://www.ecs.vuw.ac.nz/~djp/files/RV2012.ppt
Paper, "Pro ling Field Initialisation in Java", by Stephen
Nelson, David J. Pearce, and James Noble:
http://www.ecs.vuw.ac.nz/~djp/files/RV2012.pdf
Some quotations from the paper:
Unkel and Lam developed the term "stationary field" to describe
fields which are never observed to change, that is, all writes
precede all reads [for such field in all instances of the class]<
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.<
They show a little example that in D becomes similar to (I have
made them not abstract):
class Parent {
private const Child child;
public this(in Child c) pure nothrow {
this.child = c;
}
}
class Child {
private Parent parent; // can't be const
public void setParent(Parent p) pure nothrow {
this.parent = p;
}
}
void main() {
auto c = new Child;
auto p = new Parent(c); // can't be const
c.setParent(p);
}
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.<
In the end they say that maybe it's good to have language-level
support for this usage. It's quite common for language designers
to turn idioms into built-in features. In the D community a
"stationary field" is probably very similar to what's named
"logical const field".
In the last section of the paper about "Related Work", they show
links to several ideas to implement "logical const" fields:
Several works have looked at permitting type-safe late
initialisation of objects in a programming language. Summers and
Mull epresented a lightweight system for type checking delayed
object initialiation which is sufficiently expressive to handle
cyclic initialisation [6]. Fahndrich and Xia's Delayed Types
[2] use dynamically nested regions in an ownership-style type
system to represent this post-construction initialisation phase,
and ensure that programs do not access uninitialised fields.
Haack and Poll [1] have shown how these techniques can be
applied speci cally to immutability, and Leino et al. [3] show
how ownership transfer (rather than nesting) can achieve a
similar result. Qi and Myers' Masked Types [21] use type-states
to address this problem by incorporating a list of uninitialised
fields ("masked fields") into object types. Gil and Shragai [22]
address the related problem of ensuring correct initialisation
between subclass and superclass constructors within individual
objects. Based on our results, we would expect such type systems
to be of bene t to real programs.<
Even if late initialized "const" fields are not really const, and
the compiler is not able to use this information in any useful
way, they seem useful for (active and enforced) documentation and
to avoid some bugs.
Bye,
bearophile
