views:

309

answers:

5

If a string is immutable, does that mean that.... (let's assume JavaScript)

var str = 'foo';

alert(str.substr(1)); // oo

alert(str); // foo

Does it mean, when calling methods on a string, it will return the modified string, but it won't change the initial string?

If the string was mutable, does that mean the 2nd alert() would return oo as well?

+24  A: 

It means that once you instantiate the object, you can't change it's properties. In your first example you aren't changing foo. You're creating a new string. This is why in your second alert it will show "foo" instead of oo.

Does it mean, when calling methods on a string, it will return the modified string, but it won't change the initial string?

Yes. Nothing can change the string once it is created. Now this doesn't mean that you can't assign a new string object to the str variable. You just can't change the current object that str references.

If the string was mutable, does that mean the 2nd alert() would return oo as well?

Technically, no, because the substring method returns a new string. Making an object mutable, wouldn't change the method. Making it mutable means that technically, you could make it so that substring would change the original string instead of creating a new one.

Kevin
+2  A: 

Immutable means that which cannot be changed or modified.

So when you assign a value to a string, this value is created from scratch as opposed to being replaced. So everytime a new value is assigned to the same string, a copy is created. So in reality, you are never changing the original value.

SoftwareGeek
+1  A: 

From strings to stacks... a simple to understand example taken from Eric Lippert's blog:

Path Finding Using A* in C# 3.0, Part Two...

A mutable stack like System.Collections.Generic.Stack is clearly not suitable. We want to be able to take an existing path and create new paths from it for all of the neighbours of its last element, but pushing a new node onto the standard stack modifies the stack. We’d have to make copies of the stack before pushing it, which is silly because then we’d be duplicating all of its contents unnecessarily.

Immutable stacks do not have this problem. Pushing onto an immutable stack merely creates a brand-new stack which links to the old one as its tail. Since the stack is immutable, there is no danger of some other code coming along and messing with the tail contents. You can keep on using the old stack to your heart’s content.

To go deep on understaning immutability, read Eric's posts starting with this one:

Immutability in C# Part One: Kinds of Immutability

Leniel Macaferi
That quote contains an odd claim - that stack data structure (actually multiple stacks with tail-sharing) is, as a whole, a mutable structure - every push or pop changes the structure. Only the individual items are immutable. And in principle, you could have the same structure but with mutable elements. This happens in some variations of undoable union-find IIRC. Immutability has big advantages, but sharing part or all of a data structure as an optimisation is perfectly possible with mutables. Even if you want apparent immutability for other references, you can always copy-on-write as needed.
Steve314
+5  A: 

On a lower level, immutability means that the memory the string is stored in will not be modified. Once you create a string "foo", some memory is allocated to store the value "foo". This memory will not be altered. If you modify the string with, say, substr(1), a new string is created and a different part of memory is allocated which will store "oo". Now you have two strings in memory, "foo" and "oo". Even if you're not going to use "foo" anymore, it'll stick around until it's garbage collected.

One reason why string operations are comparatively expensive.

deceze
+1 thanks, this is good to know
alex
+1  A: 

I'm not certain about JavaScript, but in Java, strings take an additional step to immutability, with the "String Constant Pool". Strings can be constructed with string literals ("foo") or with a String class constructor. Strings constructed with string literals are a part of the String Constant Pool, and the same string literal will always be the same memory address from the pool.

Example:

    String lit1 = "foo";
    String lit2 = "foo";
    String cons = new String("foo");

    System.out.println(lit1 == lit2);      // true
    System.out.println(lit1 == cons);      // false

    System.out.println(lit1.equals(cons)); // true

In the above, both lit1 and lit2 are constructed using the same string literal, so they're pointing at the same memory address; lit1 == lit2 results in true, because they are exactly the same object.

However, cons is constructed using the class constructor. Although the parameter is the same string constant, the constructor allocates new memory for cons, meaning cons is not the same object as lit1 and lit2, despite containing the same data.

Of course, since the three strings all contain the same character data, using the equals method will return true.

(Both types of string construction are immutable, of course)

Brian S