Immutable data with freeze in Ruby - Deep Dive

Overview - Immutable data with freeze

What is it?

Immutable data means data that cannot be changed after it is created. In Ruby, the freeze method is used to make an object immutable by preventing any modifications to it. Once an object is frozen, attempts to change it will cause errors. This helps keep data safe and predictable in programs.

Why it matters

Without immutable data, programs can accidentally change values in unexpected ways, causing bugs that are hard to find. Freezing data ensures that once set, important values stay the same, making programs more reliable and easier to understand. It also helps when multiple parts of a program share data, preventing one part from breaking another.

Where it fits

Before learning about freezing, you should understand Ruby objects and how variables reference them. After this, you can explore deeper concepts like thread safety, functional programming, and how immutability helps in concurrent code.

Mental Model

Core Idea

Freezing an object locks it so no one can change it anymore, making it permanently fixed.

Think of it like...

Imagine writing a message on a whiteboard and then covering it with a clear plastic sheet. Now, no one can erase or change the message underneath, keeping it exactly as it was.

Object (modifiable) ──freeze──▶ Object (immutable)
  │                            │
  ▼                            ▼
Can change                 Cannot change
properties                properties or values

Build-Up - 7 Steps

1

Foundation

Understanding Ruby objects and mutability

Concept: Objects in Ruby can usually be changed after creation, which is called mutability.

In Ruby, most objects like strings and arrays can be modified. For example, you can add elements to an array or change characters in a string. This is normal behavior and useful for many tasks.

Result

You can change the contents of objects freely, like adding items to an array or changing string letters.

Knowing that Ruby objects are mutable by default helps you understand why freezing is needed to prevent changes.

2

Foundation

What does freeze do in Ruby?

Concept: The freeze method makes an object immutable, stopping any future changes.

Calling freeze on an object locks it. For example, calling freeze on a string means you cannot change its characters anymore. If you try, Ruby raises an error.

Result

Frozen objects cannot be changed; attempts to modify them cause errors.

Understanding freeze is key to controlling when and how data can be changed in your program.

3

Intermediate

Freezing different object types

🤔Before reading on: do you think freezing an array also freezes the objects inside it? Commit to your answer.

Concept: Freezing an object only freezes that object, not the objects it contains inside.

If you freeze an array, you cannot add or remove elements, but the elements themselves can still be changed if they are mutable. For example, freezing an array of strings stops adding/removing strings, but you can still change the strings unless they are frozen too.

Result

Only the container is frozen; contained objects remain mutable unless frozen separately.

Knowing that freeze is shallow helps avoid bugs where inner data changes unexpectedly.

4

Intermediate

Checking if an object is frozen

Concept: Ruby provides a method to check if an object is frozen or not.

You can call frozen? on any object to see if it is frozen. It returns true if the object is frozen, false otherwise. This helps you write safer code by checking before modifying.

Result

You can detect frozen objects and avoid errors by checking frozen? before changes.

Using frozen? helps prevent runtime errors and makes your code more robust.

5

Intermediate

Freezing nested objects deeply

🤔Before reading on: do you think Ruby has a built-in way to freeze an object and all objects inside it deeply? Commit to your answer.

Concept: Ruby's freeze is shallow, but you can write code to freeze objects deeply, including nested ones.

To freeze an object and all objects inside it, you need to write a method that recursively calls freeze on the object and its contents. This ensures complete immutability for complex data structures.

Result

You can create fully immutable nested data by freezing all parts deeply.

Understanding shallow vs deep freeze is crucial for managing complex data safely.

6

Advanced

Why frozen objects improve thread safety

🤔Before reading on: do you think freezing objects alone guarantees thread safety? Commit to your answer.

Concept: Frozen objects cannot be changed, so they can be safely shared between threads without locks.

In multi-threaded Ruby programs, mutable shared data can cause conflicts. Frozen objects prevent changes, so threads can read them safely without synchronization. However, freezing alone does not guarantee full thread safety if other mutable data is involved.

Result

Frozen objects reduce risks of data races and make concurrent code safer.

Knowing how immutability relates to thread safety helps write better concurrent programs.

7

Expert

Surprising behavior with frozen objects and dup

🤔Before reading on: do you think dup on a frozen object returns a frozen or unfrozen copy? Commit to your answer.

Concept: Calling dup on a frozen object returns an unfrozen copy, allowing modifications on the duplicate.

When you call dup on a frozen object, Ruby creates a shallow copy that is not frozen. This means you can modify the duplicate without affecting the original frozen object. This behavior is useful but can be surprising if you expect the copy to remain frozen.

Result

dup breaks immutability by creating a modifiable copy of a frozen object.

Understanding dup's behavior prevents bugs where frozen data is unintentionally changed through copies.

Under the Hood

Ruby objects have an internal flag that marks them as frozen. When freeze is called, this flag is set. Any method that tries to modify the object checks this flag and raises a RuntimeError if the object is frozen. This check happens at runtime for every mutating method call.

Why designed this way?

Freeze was designed to be simple and efficient by using a flag rather than copying or locking data. This allows quick checks without heavy overhead. The shallow freeze approach keeps performance reasonable, while giving programmers control to freeze nested objects if needed.

┌───────────────┐
│ Ruby Object   │
│ ┌───────────┐ │
│ │ frozen?   │─┼─▶ true/false flag
│ └───────────┘ │
│               │
│ Methods check │
│ frozen? flag  │
│ before change │
└──────┬────────┘
       │
       ▼
  If frozen? == true
  ────────────────▶ Raise error on modification

Myth Busters - 4 Common Misconceptions

Quick: Does freezing an array also freeze the objects inside it? Commit to yes or no before reading on.

Common Belief: Freezing an array makes everything inside it immutable too.

Reality: Freezing an array only prevents changing the array itself, not the objects inside it.

Why it matters: Assuming deep freeze causes bugs when inner objects are changed unexpectedly, breaking immutability assumptions.

Quick: Does dup on a frozen object return a frozen copy? Commit to yes or no before reading on.

Common Belief: Duplicating a frozen object keeps it frozen.

Reality: dup returns an unfrozen copy, allowing changes to the duplicate.

Why it matters: This can lead to accidental mutations of data thought to be immutable, causing subtle bugs.

Quick: Does freezing an object guarantee thread safety? Commit to yes or no before reading on.

Common Belief: Frozen objects are always safe to use in any thread without issues.

Reality: While frozen objects cannot be changed, thread safety depends on all shared data being immutable and no other mutable state.

Why it matters: Relying solely on freeze for thread safety can cause race conditions if other mutable data is accessed concurrently.

Quick: Can you unfreeze an object once frozen? Commit to yes or no before reading on.

Common Belief: You can unfreeze an object by calling some method or duplicating it.

Reality: Objects cannot be unfrozen; freeze is permanent for that object instance.

Why it matters: Trying to unfreeze leads to confusion and misuse of freeze, causing design mistakes.

Expert Zone

1

Freezing is shallow by design to keep performance high and give programmers control over nested data immutability.

2

Frozen objects still allow instance variables to be reassigned if they hold mutable objects, so deep immutability requires careful design.

3

Using freeze in combination with frozen string literals (introduced in Ruby 2.3) can optimize memory and performance by reusing immutable strings.

When NOT to use

Do not use freeze when you need to modify objects later or when working with large nested structures where deep immutability is required; instead, consider using immutable data structures from gems like 'immutable' or functional programming techniques.

Production Patterns

In production, freeze is often used to lock configuration data, constants, and shared resources to prevent accidental changes. It is also used in libraries to protect internal state and improve thread safety without heavy locking.

Connections

Functional programming

Builds-on

Understanding freeze helps grasp immutability, a core principle in functional programming that avoids side effects and makes code easier to reason about.

Concurrency and thread safety

Builds-on

Knowing how freeze prevents data changes aids in designing thread-safe programs by sharing immutable data without locks.

Legal contracts

Analogy in different field

Just like freezing an object locks it from changes, a signed legal contract locks agreements so parties cannot change terms later, ensuring trust and predictability.

Common Pitfalls

#1 Assuming freezing an array freezes its elements too.

Wrong approach:

arr = ["hello", "world"]
arr.freeze
arr[0].upcase! # This changes the string inside the frozen array

Correct approach:

arr = ["hello", "world"]
arr.each(&:freeze)
arr.freeze
arr[0].upcase! # Raises error because string is also frozen

Root cause:

Misunderstanding that freeze is shallow and does not affect nested objects.

#2 Expecting dup to keep the frozen state of an object.

Wrong approach:

str = "hello".freeze
copy = str.dup
copy << "!" # This works and modifies copy

Correct approach:

str = "hello".freeze
copy = str.dup.freeze
copy << "!" # Raises error because copy is frozen explicitly

Root cause:

Not realizing dup returns an unfrozen copy by default.

#3 Trying to unfreeze an object after freezing it.

Wrong approach:

obj = "data".freeze
obj.unfreeze # No such method, error

Correct approach:

obj = "data".freeze
obj = obj.dup # Create a new unfrozen copy instead

Root cause:

Believing freeze can be reversed on the same object instance.

Key Takeaways

Freezing in Ruby makes objects immutable by setting an internal flag that prevents changes.

Freeze is shallow: it locks only the object itself, not nested objects inside it.

Frozen objects help prevent bugs by ensuring data does not change unexpectedly, especially in shared or concurrent contexts.

dup on a frozen object returns an unfrozen copy, which can be modified unless frozen again.

Understanding freeze deeply improves code safety, thread safety, and helps write more predictable Ruby programs.

Practice

1. What does the freeze method do to an object in Ruby?

easy

A. Prevents any further modifications to the object

B. Deletes the object from memory

C. Duplicates the object

D. Makes the object mutable

Solution

1. Step 1: Understand the purpose of freeze

   The freeze method is used to make an object immutable, meaning it cannot be changed after freezing.

2. Step 2: Identify the effect on the object

   Once frozen, any attempt to modify the object will raise an error, so it prevents further changes.

3. Final Answer:

   Prevents any further modifications to the object -> Option A

4. Quick Check:

   freeze makes object immutable = Prevents changes [OK]

Hint: Freeze means no changes allowed after calling it [OK]

Common Mistakes:

• Thinking freeze deletes the object
• Confusing freeze with duplication
• Assuming freeze makes object mutable

2. Which of the following is the correct way to freeze a string name in Ruby?

easy

A. freeze(name)

B. name.frozen = true

C. name.freeze()

D. freeze name

Solution

1. Step 1: Recall Ruby method call syntax

   In Ruby, to call a method on an object, use dot notation like object.method().

2. Step 2: Identify the correct freeze syntax

   The correct way to freeze the string name is name.freeze(). Other options are invalid syntax or incorrect usage.

3. Final Answer:

   name.freeze() -> Option C

4. Quick Check:

   Method call with dot and parentheses = Correct freeze syntax [OK]

Hint: Use dot notation: object.freeze() to freeze [OK]

Common Mistakes:

• Using freeze as a standalone function
• Trying to assign frozen = true
• Omitting dot before freeze

3. What will be the output of this Ruby code?

arr = [1, 2, 3]
arr.freeze
arr << 4
puts arr.inspect

medium

A. [1, 2, 3, 4]

B. RuntimeError: can't modify frozen Array

C. [1, 2, 3]

D. SyntaxError

Solution

1. Step 1: Understand freezing the array

   The array arr is frozen using arr.freeze, making it immutable.

2. Step 2: Analyze the modification attempt

   Trying to append 4 with arr << 4 will raise a RuntimeError because the array is frozen and cannot be changed.

3. Final Answer:

   RuntimeError: can't modify frozen Array -> Option B

4. Quick Check:

   Frozen object + modification = RuntimeError [OK]

Hint: Modifying frozen object causes RuntimeError [OK]

Common Mistakes:

• Assuming frozen array can still be changed
• Expecting silent failure or no error
• Confusing output with syntax error

4. Identify the error in this Ruby code snippet:

str = "hello"
str.freeze
str[0] = 'H'
puts str

medium

A. RuntimeError: can't modify frozen String

B. SyntaxError due to invalid string modification

C. No error, output is "Hello"

D. Output is "hello" without changes

Solution

1. Step 1: Recognize string freezing effect

   The string str is frozen, so it cannot be changed after str.freeze.

2. Step 2: Understand the attempted modification

   Trying to change the first character with str[0] = 'H' raises a RuntimeError because the string is frozen.

3. Final Answer:

   RuntimeError: can't modify frozen String -> Option A

4. Quick Check:

   Frozen string + modification = RuntimeError [OK]

Hint: Frozen string cannot be changed, causes RuntimeError [OK]

Common Mistakes:

• Thinking string changes silently fail
• Expecting output "Hello" without error
• Confusing syntax error with runtime error

5. Given this code, what is the best way to safely modify a frozen array without error?

original = [10, 20, 30].freeze
# Your code here to add 40

hard

A. original.freeze(false)

B. original << 40

C. original.push(40)

D. original = original.dup << 40

Solution

1. Step 1: Understand frozen array cannot be changed

   The array original is frozen, so direct modification like << or push will cause errors.

2. Step 2: Use duplication to create a modifiable copy

   Using original.dup creates a new unfrozen copy. Then appending 40 to this copy is allowed.

3. Step 3: Assign the modified copy back

   Assigning the new array with 40 added back to original variable safely updates it without error.

4. Final Answer:

   original = original.dup << 40 -> Option D

5. Quick Check:

   Duplicate frozen object before modifying = Safe change [OK]

Hint: Duplicate frozen object before changing it [OK]

Common Mistakes:

• Trying to modify frozen array directly
• Using non-existent freeze(false) method
• Assuming push works on frozen array