At 9:07 PM -0700 4/27/06, Mark A. Biggar wrote:
I'm not sure that immutable make any sense as a concept separate from
constant. A truly immutable object can't even be initialized, it has to
be born ex-nilo already with a value.
Well, that depends on your philosophy.
I would argue that, philosophically, all values that can possibly
exist in the universal set have already existed and will continue to
exist eternally. By definition, a 'value' is both unique and
immutable. A value does not to be born in any sense because it is
eternal. Moreover, every 'value' is of a type, where that type is
defined as a subset of the universal set; a type can have values that
are arbitrarily complex or large, and less complex values have no
more claim to being a valid value than a more complex one.
While every value is unique, each one can have multiple appearances,
and for the sake of discussion, each appearance is the content of a
container, whether that container is updateable/mutable or
constant/immutable; each container is also of a type and can only
hold an appearance of a value of its type. Moreover, every container
always holds a value of its type at all times.
For example, there is only one value that is the number 42. If you
have a number variable containing 42, and you then update that
variable to contain the number 45 instead, you have not changed the
value 42 into a 45, but rather replaced its appearance in the
variable with an appearance of 45.
A related matter is that two things are considered equal if and only
if they are in fact two appearances of the *same* value.
So that's how things are conceptually, as I see it.
In some sense, I suppose this all sounds like quantum physics.
Now, our implementations of these concepts in a computer, regardless
of how we phrase it with syntax, all involve containers that are
some-how addressable; at some point in time, each is given an
appearance of a value, then depending on whether we declare the
container to be immutable/constant/non-updateable or
mutable/variable/updateable, it can possibly be made to hold an
appearance of a different value. An object is a container and it is
reasonable on a per-class basis that objects of that class can be
updateable or not.
Long story shortened, if we consider the point in time where an
"immutable" object's constructor returns as being when the object is
born, then we have no problem. Any type of object is thereby
immutable if it can not be changed after its constructor returns.
So, we should just stick with variable and
constant (assigned once doesn't change afterwards) containers and not
use the term immutable at all.
I may be fine with this idea if we want to do it. But in the
mean-time, I will probably consider "immutable" and "mutable" to be
synoymous with "constant" and "variable".
I think that only values (like 1, "ABC" and a set constant like
(1|2|5|9)) are immutable.
Why stop there. I would argue that it should be possible to have a
type of any level of complexity that is declared immutable, such that
an object of that type isn't changed after its constructor finishes.
Denying this possibility on some arbitrary basis like with your list
makes as much sense as taking several things larger than a bit and
saying that some are atomic while others aren't.
-- Darren Duncan
