www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A study on immutability usage

reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Oct 01 2012
next sibling parent "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Monday, 1 October 2012 at 12:28:33 UTC, bearophile wrote:

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




I've started to feel that when trying to be more const correct. I 
haven't put any thought in how I can/should/want to solve this or 
another related one I'm having.

I've had some containers which would be prefect as immutable, but 
there is a lot of effort to fill up all their data. The simple 
solution is to do some casting, I just haven't had time to see if 
a better design exists to create immutable and prevent mutable 
pointers. Pure doesn't work since data comes from disk.

Anyway, nice to see similar issues found in research.
Oct 01 2012
prev sibling next sibling parent reply "Bernard Helyer" <b.helyer gmail.com> writes:
Our results from 14 Java applications


Only 14? So it's a useless statistic. Good to know.
The rest seemed interesting.
Oct 01 2012
parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 10/01/2012 09:39 PM, Bernard Helyer wrote:

 Our results from 14 Java applications


 Only 14? So it's a useless statistic.


No, that isn't true. How many language decisions in D are based on an 
analysis of even 5 programs, let alone 14? What if you were testing to 
see how fair a coin was, and it came up heads 14 times in a row? Would 
you have a very strong suspicion that the coin was biased? This isn't an 
idle question, as this kind of question happens a lot during preliminary 
testing of medical treatments, for example.

How many examples you have to look at depends on what you are looking 
for and the kind of results you get.
Oct 02 2012
parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2012-10-03 at 00:37 -0400, Jeff Nowakowski wrote:

 On 10/01/2012 09:39 PM, Bernard Helyer wrote:

 Our results from 14 Java applications


 Only 14? So it's a useless statistic.


=20
 No, that isn't true. How many language decisions in D are based on an=20
 analysis of even 5 programs, let alone 14? What if you were testing to=


=20

 see how fair a coin was, and it came up heads 14 times in a row? Would=


=20

 you have a very strong suspicion that the coin was biased? This isn't an=


=20

 idle question, as this kind of question happens a lot during preliminary=


=20

 testing of medical treatments, for example.
=20
 How many examples you have to look at depends on what you are looking=20
 for and the kind of results you get.


If we were to study software now in the way Richard Helm, Erich Gamma et
al. did in the early 1990s would we find Proxy, Fa=C3=A7ade, Builder, etc. =
of
course we would since the feedback loop of people knowing about them
causes them to use them. So we now have a self-fulfilling prophesy, and
a design loop it is impossible to escape from. =20

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Oct 03 2012
parent reply "Jesse Phillips" <jessekphillips+D gmail.com> writes:
On Wednesday, 3 October 2012 at 08:17:49 UTC, Russel Winder wrote:

 If we were to study software now in the way Richard Helm, Erich 
 Gamma et
 al. did in the early 1990s would we find Proxy, Façade, 
 Builder, etc. of
 course we would since the feedback loop of people knowing about 
 them
 causes them to use them. So we now have a self-fulfilling 
 prophesy, and
 a design loop it is impossible to escape from.


So, you are saying that these examples are exhibiting the same 
problems because they are based on the same design?

I don't see how that would invalidate the results. That is, I 
don't see the relevance here.
Oct 03 2012
parent Russel Winder <russel winder.org.uk> writes:
On Thu, 2012-10-04 at 03:49 +0200, Jesse Phillips wrote:
[=E2=80=A6]

 So, you are saying that these examples are exhibiting the same=20
 problems because they are based on the same design?
=20
 I don't see how that would invalidate the results. That is, I=20
 don't see the relevance here.


My comment relates to Jeff's point that what you find is determined by
what you are looking for.  Also that what people write is determined by
what they have been told is good and so the use of GoF patterns is what
will be found now as then. No commentary was intended on any previous
posts in the thread.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Oct 04 2012
prev sibling next sibling parent "renoX" <renozyx gmail.com> writes:
Interesting, I vaguely remember that Eiffel has a 'once' keyword, 
but I'm not sure if it could help here.
Oct 02 2012
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
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.
Oct 02 2012
prev sibling parent "jdrewsen" <jdrewsen nospam.com> writes:
On Monday, 1 October 2012 at 12:28:33 UTC, bearophile wrote:

 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/


...



http://msdn.microsoft.com/en-us/library/acdd6hb7(v=vs.71).aspx

/Jonas
Oct 05 2012