Re: Immutable and Transient Objects and GC?

[Maciej Sobczak <see.my.homepage@gmail.com>]

On 18 Mar, 21:07, Dimonax <dimo...@nospam.net> wrote:

> An Immutable Object, conceptually, is pretty clear.

Even though there is a bit of hype around immutable objects recently,
related to the hopes that this automagically solves concurrency
problems (which ones, really?), I do not think that it can become a
mainstream approach in languages like Ada.
The problem is that Ada is really a value-oriented language (and not a
reference-oriented one) and there are lots of fundamental language
constructs that promote or even require mutability: 'out' and 'in out'
parameter modes are just examples. Also, there is a strong culture of
avoiding, or at least not overusing, dynamic memory allocation and
this requires mutable state for recycling objects.
In other words, mutability is part of the language spirit.

In addition and just IMHO, immutability cannot be a solution for
anything, because it distorts what should be a natural design of a
given program. What I mean by natural is that (im)mutability of any
given object should come out from the main problem analysis and not
from elsewhere - trying to solve whatever concurrency issues you have
is that "elsewhere" because it has nothing to do with what the given
object represents.
In other words, if the given object *happens* to be immutable as a
result of the problem analysis and this fact can help with
concurrency, then it is a worthy coincidence; but when immutability of
objects is *imposed* in order to solve some unrelated concurrency (or
other) issues, then it is just a design distortion.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada