Read only, frozen, and immutable collections

The topics of immutability and functional programming has fascinated me lately.  Mostly because of my work on the Visual Studio Common Project System (CPS) which is a large, highly multi-threaded code base that only remains sane because of its reliance on immutable types in many areas.

In my research and conversations on this topic, I’ve learned to appreciate the differences between several adjectives often used interchangeably among programmers that I’d like to share with you, detailing the differences including some pros and cons of each.  At the bottom of the post I include a summary table and my own personal verdict for what kinds of collections (mutable and immutable) I prefer.

Although the principles here apply to any type in any language and platform, I’ll be using for some references and examples the collection types in the .NET base class library.

First a little terminology as I will use it in this post:

    Mutable (a.k.a read/write): a collection or type that allows for in-place updates that anyone with a reference to that object may observe.
    Immutable: a collection or type that cannot be changed at all, but can be efficiently mutated by allocating a new collection that shares much of the same memory with the original, but has new memory describing the change.
    Freezable: a collection or type that is mutable until some point in time when it is frozen, after which it cannot be changed.
    Read only: a reference whose type does not permit mutation of the underlying data, which is usually mutable by another reference.

The de facto read only standards in .NET

There are not yet any freezable or immutable collections included in the  .NET base class library.  But we have a couple of read-only views of data, as outlined below.

De facto standard #1: IEnumerable<T>

Read more: Andrew Arnott
QR:

Posted via email from Jasper-net