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

Reply via email to