A study on immutability usage

[bearophile]

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


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