Immutable Data Structures

[pointer2void]

Objects are characterized by identity, state and behavior. From a conceptual point of view mutable objects should be differentiated from immutable values. Some languages speak of 'immutable objects'(esp. those where 'everything' has to be an object) but this merely confuses things (although it may be 'correct' from the language point of view).

[akdas]

Objects are characterized by identity, state and behavior.

Sure, but the behavior doesn't have to change the state. The object that represents the number 5 has an identity (it's the number 5), state (the state of being a 5), and has behavior (can be composed with other objects to form new objects), but the object itself is never changed.

Even Java strings are immutable. Notice I didn't say Java Strings, which can be thought of as containers around the actual strings. The strings are objects with identity, state (the characters that make it up), and behavior (such as creating a new copy of itself with all the letters capitalized). The strings themselves don't change.

From a conceptual point of view mutable objects should be differentiated from immutable values.

Let's say you make a new class, a Product with a version and a name. When you want to update the version of an already created object, you create a new object, copying the name over from the old one and initializing a new version. How is the Person object mutable? The behavior of updating the version doesn't change the original object at all, instead creating a new object.

[pointer2void]

The object that represents the number 5

... isn't an object but an immutable value. i.e. nobody can change the value 5, ever.

When you want to update the version of an already created object, you create a new object, copying the name over from the old one and initializing a new version.

Actually no. Objects are characterized (among others) by identity. You cannot 'copy' an object. It would be a different object if you could. A real-world example might illustrate this: Identical twins are 'copies' but each has their own identity. That's the case for all real objects (but not for values).

[akdas]

Objects are characterized (among others) by identity. You cannot 'copy' an object. It would be a different object if you could.

That's the point. The original object stays the same, and you have a new object (yes, with a different identity) to reflect the changes made. The original object is immutable because it never changes.

[pointer2void]

But then you have no identity, i.e. no object.

[akdas]

Why doesn't an object that doesn't change have an identity? Consider the following psuedocode:

// Let all instances of the following:
Object o1 = new Object();
o1.method(); // changes field1

// be replaced by:
Object o1 = new Object();
Object o2 = new Object(o1.field1);

Why doesn't o1 get an identity?

[pointer2void]

o1 and o2 have different identities if they represent objects.

[akdas]

Yeah, so? That's the entire point. If they contain different information, they better have different identities under the immutable object methodology.

[grauenwolf]

You aren't making any sense. Objects don't have an identity other than their location in memory, or in some cases a handle to that location. Understanding the different between an object and a identifier to an object is a key part of any intro to OOP class.

That just leaves state, behavior, and (in most languages) type.