The true definition of immutability?

Question

I am wondering how immutability is defined? If the values aren\'t exposed as public, so can\'t be modified, then it\'s enough?

Can the values be modified inside the type

Answer 1

I've learned that immutability is when you set everything in the constructor and cannot modify it later on during the lifetime of the object.

Answer 2

The definition of immutability can be located on Google .

Example:

immutable - literally, not able to change.
www.filosofia.net/materiales/rec/glosaen.htm

In terms of immutable data structures, the typical definition is write-once-read-many, in other words, as you say, once created, it cannot be changed.

There are some cases which are slightly in the gray area. For instance, .NET strings are considered immutable, because they can't change, however, StringBuilder internally modifies a String object.

Answer 3

There's unfortunately no immutable keywords in c#/vb.net, though it has been debated, but if there's no autoproperties and all fields are declared with the readonly (readonly fields can only bet assigned in the constructor) modfier and that all fields is declared of an immutable type you will have assured your self immutability.

Answer 4

An immutable object is one whose observable state can never be changed by any plausible sequence of code execution. An immutable type is one which guarantees that any instances exposed to the outside world will be immutable (this requirement is often stated as requiring that the object's state may only be set in its constructor; this isn't strictly necessary in the case of objects with private constructors, nor is it sufficient in the case of objects which call outside methods on themselves during construction).

A point which other answers have neglected, however, is a definition of an object's state. If Foo is a class, the state of a List<Foo> consists of the sequence of object identities contained therein. If the only reference to a particular List<Foo> instance is held by code which will neither cause that sequence to be changed, nor expose it to code that might do so, then that instance will be immutable, regardless of whether the Foo objects referred to therein are mutable or immutable.

To use an analogy, if one has a list of automobile VINs (Vehicle Identification Numbers) printed on tamper-evident paper, the list itself would be immutable even though cars aren't. Even if the list contains ten red cars today, it might contain ten blue cars tomorrow; they would still, however, be the same ten cars.

Answer 5

Lots of questions there. I'll try to answer each of them individually:

• "I am wondering how immutability is defined?" - Straight from the Wikipedia page (and a perfectly accurate/concise definition)

  An immutable object is an object whose state cannot be modified after it is created

• "If the values aren't exposed as public, so can't be modified, then it's enough?" - Not quite. It can't be modified in any way whatsoever, so you've got to insure that methods/functions don't change the state of the object, and if performing operations, always return a new instance.

• "Can the values be modified inside the type, not by the customer of the type?" - Technically, it can't be modified either inside or by a consumer of the type. In pratice, types such as System.String (a reference type for the matter) exist that can be considered mutable for almost all practical purposes, though not in theory.

• "Or can one only set them inside a constructor?" - Yes, in theory that's the only place where state (variables) can be set.

• "If so, in the cases of double initialization (using the this keyword on structs, etc) is still ok for immutable types?" - Yes, that's still perfectly fine, because it's all part of the initialisation (creation) process, and the instance isn't returned until it has finished.

• "How can I guarantee that the type is 100% immutable?" - The following conditions should insure that. (Someone please point out if I'm missing one.)

  1. Don't expose any variables. They should all be kept private (not even protected is acceptable, since derived classes can then modify state).
  2. Don't allow any instance methods to modify state (variables). This should only be done in the constructor, while methods should create new instances using a particular constructor if they require to return a "modified" object.
  3. All members that are exposed (as read-only) or objects returned by methods must themselves be immutable.

  Note: you can't insure the immutability of derived types, since they can define new variables. This is a reason for marking any type you wan't to make sure it immutable as sealed so that no derived class can be considered to be of your base immutable type anywhere in code.

Hope that helps.

Answer 6

The previous posters have already stated that you should assign values to your fields in the constructor and then keep your hands off them. But that is sometimes easier said than done. Let's say that your immutable object exposes a property of the type List<string>. Is that list allowed to change? And if not, how will you control it?

Eric Lippert has written a series of posts in his blog about immutability in C# that you might find interesting: you find the first part here.