Editing Immutable object (section)

== Concepts ==

=== Immutable variables ===
In [[imperative programming]], values held in [[program variable]]s whose content never changes are known as ''[[Constant (programming)|constants]]'' to differentiate them from variables that could be altered during execution. Examples include conversion factors from meters to feet, or the value of [[pi]] to several decimal places.

Read-only fields may be calculated when the program runs (unlike constants, which are known beforehand), but never change after they are initialized.

=== Weak vs strong immutability ===
Sometimes, one talks of certain ''fields'' of an object being immutable. This means that there is no way to change those parts of the object state, even though other parts of the object may be changeable (''weakly immutable''). If all fields are immutable, then the object is immutable. If the whole object cannot be extended by another class, the object is called ''strongly immutable''.<ref>{{cite web
 | url    = http://www.javaranch.com/journal/2003/04/immutable.htm
 | title  = Mutable and Immutable Objects: Make sure methods can't be overridden.
 | author = David O'Meara
 | date   = April 2003
 | work   = Java Ranch
 | quote  = The preferred way is to make the class final. This is sometimes referred to as "Strong Immutability". It prevents anyone from extending your class and accidentally or deliberately making it mutable.
 | access-date = 2012-05-14
}}</ref> This might, for example, help to explicitly enforce certain invariants about certain data in the object staying the same through the lifetime of the object. In some languages, this is done with a keyword (e.g. <code>const</code> in [[C++]], <code>final</code> in [[Java (programming language)|Java]]) that designates the field as immutable. Some languages reverse it: in [[OCaml]], fields of an object or record are by default immutable, and must be explicitly marked with <code>mutable</code> to be so.

=== References to objects ===
In most [[object-oriented programming language|object-oriented languages]], objects can be referred to using [[reference (computer science)|references]]. Some examples of such languages are [[Java (programming language)|Java]], [[C++]], [[C Sharp (programming language)|C#]], [[VB.NET]], and many [[scripting language]]s, such as [[Perl]], [[Python (programming language)|Python]], and [[Ruby programming language|Ruby]]. In this case, it matters whether the state of an object can vary when objects are shared via references.

=== Referencing vs copying objects ===
If an object is known to be immutable, it is preferred to create a [[reference (computer science)|reference]] of it instead of copying the entire object. This is done to conserve memory by preventing data duplication and avoid calls to constructors and destructors; it also results in a potential boost in execution speed.

The reference copying technique is much more difficult to use for mutable objects, because if any user of a mutable object reference changes it, all other users of that reference see the change. If this is not the intended effect, it can be difficult to notify the other users to have them respond correctly. In these situations, [[defensive copy]]ing of the entire object rather than the reference is usually an easy but costly solution. The [[observer pattern]] is an alternative technique for handling changes to mutable objects.

=== Copy-on-write ===
A technique that blends the advantages of '''mutable''' and '''immutable''' objects, and is supported directly in almost all modern hardware, is [[copy-on-write]] (COW). Using this technique, when a user asks the system to copy an object, it instead merely creates a new reference that still points to the same object. As soon as a user attempts to modify the object through a particular reference, the system makes a real copy, applies the modification to that, and sets the reference to refer to the new copy. The other users are unaffected, because they still refer to the original object. Therefore, under COW, all users appear to have a mutable version of their objects, although in the case that users do not modify their objects, the space-saving and speed advantages of immutable objects are preserved. Copy-on-write is popular in [[virtual memory]] systems because it allows them to save memory space while still correctly handling anything an application program might do.

=== Interning ===
The practice of always using references in place of copies of equal objects is known as ''[[intern (computer science)|interning]]''. If interning is used, two objects are considered equal if and only if their references, typically represented as pointers or integers, are equal. Some languages do this automatically: for example, [[Python (programming language)|Python]] automatically [[String intern pool|interns short strings]]. If the algorithm that implements interning is guaranteed to do so in every case that it is possible, then comparing objects for equality is reduced to comparing their pointers – a substantial gain in speed in most applications. (Even if the algorithm is not guaranteed to be comprehensive, there still exists the possibility of a [[fast path]] case improvement when the objects are equal and use the same reference.) Interning is generally only useful for immutable objects.

=== Thread safety ===
Immutable objects can be useful in multi-threaded applications. Multiple threads can act on data represented by immutable objects without concern of the data being changed by other threads. Immutable objects are therefore considered more ''[[thread-safe]]'' than mutable objects.

=== Violating immutability ===
Immutability does not imply that the object as stored in the computer's [[Computer storage|memory]] is unwriteable. Rather, immutability is a [[compile-time]] construct that indicates what a programmer can do through the normal interface of the object, not necessarily what they can absolutely do (for instance, by circumventing the type system or violating [[const correctness]] in [[C (programming language)|C]] or [[C++]]).