0 Replies - 4557 Views - Last Post: 20 January 2013 - 11:58 PM

#1 macosxnerd101  Icon User is online

  • Games, Graphs, and Auctions
  • member icon

Reputation: 11039
  • View blog
  • Posts: 41,325
  • Joined: 27-December 08

[Link] Clojure- On Structural Immutability

Post icon  Posted 20 January 2013 - 11:58 PM


Why should you care about structural immutability?

Well it turns out that structurally immutable objects have some nice and useful properties.

-Performance. Mutability is a necessary evil. As a Clojure developer, Im happiest when everything is pure and immutable. But for performance reasons, you sometimes need to resort to mutable data structures. Immutability can mean the creation of a *lot* of new objects, which can cause significant performance issues and GC pressure. Structurally immutable objects can generally match the performance of fully mutable data structures for most operations. Indeed, Java arrays (which are structurally immutable) are the usual choice for people wanting to write highly optimised algorithms with mutable data in both Java and Clojure.
-Structurally immutable objects offer better thread-safety typically a individual component in a structurally immutable collection can be mutated with a single atomic operation (e.g. updating a value in a Java array). This can be enough to satisfy your thread safety requirements *without locking* a structurally immutable object can therefore be treated as equivalent to a collection of Clojure atoms. Compare with data structures that allow structural modification (e.g. ArrayList) and you will find that they are fundamentally unsafe under concurrent modification.
-Structural sharing becomes possible. Normally structural sharing is associated with immutable data structures, but it also works for structurally immutable objects. This isnt possible with completely mutable data structures, since structural modifications would break the structural sharing.
-Structurally immutable objects compose - that is, you can glue two structurally immutable objects together and create a new structurally immutable object. This can exploit structural sharing by just keeping two references to the original object being composed, i.e. the new composed object can be extremely lightweight.
-Mutable sub-views can be supported, once again via structural sharing. You can create a view into a subset of structurally immutable data structure, where changes to the view also change the underlying data and vice versa


Is This A Good Question/Topic? 0
  • +

Page 1 of 1