Readonly properties in PHP - Deep Dive

Overview - Readonly properties

What is it?

Readonly properties in PHP are special class properties that can only be assigned once, usually during object creation. After they are set, their values cannot be changed. This means you can create objects with fixed data that cannot be accidentally modified later.

Why it matters

Readonly properties help prevent bugs caused by unexpected changes to important data inside objects. Without them, developers might accidentally overwrite values, causing unpredictable behavior. They make code safer and easier to understand by clearly showing which data should stay constant.

Where it fits

Before learning readonly properties, you should understand basic PHP classes and properties. After this, you can explore immutability patterns and advanced object design concepts like value objects and data transfer objects.

Mental Model

Core Idea

Readonly properties are like sealed envelopes: you can put a letter inside once, but you cannot change it afterward.

Think of it like...

Imagine writing a message on a whiteboard and then covering it with a transparent plastic sheet. You can see the message clearly, but you cannot erase or change it anymore. Readonly properties work the same way for data inside objects.

┌─────────────────────────────┐
│         Object              │
│ ┌───────────────┐           │
│ │ Readonly Prop │───set once│
│ └───────────────┘           │
│           │                 │
│           ▼                 │
│    Value locked in          │
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

Basic class properties in PHP

Concept: Learn how to define and use normal class properties.

name = "Alice"; echo $person->name; ?>

Result

Alice

Understanding how normal properties work is essential before learning how readonly properties differ.

2

Foundation

What is immutability in objects

Concept: Introduce the idea that some data should not change after creation.

In many programs, some information should stay the same once set, like a person's birthdate. Immutability means making data fixed to avoid accidental changes.

Result

You understand why some properties should not be changed after setting.

Knowing immutability helps appreciate why readonly properties exist.

3

Intermediate

Declaring readonly properties in PHP 8.1+

🤔Before reading on: do you think readonly properties can be changed after the constructor? Commit to your answer.

Concept: PHP 8.1 introduced the readonly keyword to declare properties that can only be assigned once.

email = $email; // Allowed } } $user = new User("[e-mail]"); echo $user->email; // $user->email = "[e-mail]"; // Error: Cannot modify readonly property ?>

Result

[e-mail]

Understanding that readonly properties can only be set once, typically in the constructor, prevents accidental reassignment bugs.

4

Intermediate

Readonly properties and object cloning

🤔Before reading on: do you think cloning an object copies readonly properties as-is or resets them? Commit to your answer.

Concept: When cloning objects with readonly properties, the readonly values are copied and remain immutable in the clone.

version = $version; } } $config1 = new Config("1.0"); $config2 = clone $config1; echo $config2->version; // Outputs 1.0 // $config2->version = "2.0"; // Error: Cannot modify readonly property ?>

Result

1.0

Knowing how cloning interacts with readonly properties helps avoid surprises when duplicating objects.

5

Intermediate

Readonly properties with typed classes

Concept: Readonly properties work well with typed properties to enforce both immutability and type safety.

x = $x; $this->y = $y; } } $point = new Point(3.5, 7.2); echo "X: {$point->x}, Y: {$point->y}"; ?>

Result

X: 3.5, Y: 7.2

Combining readonly with types ensures data is both fixed and valid, improving code reliability.

6

Advanced

Readonly properties and inheritance rules

🤔Before reading on: can a child class override a readonly property as writable? Commit to your answer.

Concept: Readonly properties cannot be overridden as writable in child classes; the readonly constraint is preserved.

id = $id; } } class Child extends Base { // public int $id; // Error: Cannot override readonly property with writable } ?>

Result

Error if trying to override readonly as writable

Understanding inheritance restrictions prevents breaking immutability guarantees in subclasses.

7

Expert

Readonly properties and internal mutation loopholes

🤔Before reading on: do you think readonly properties guarantee absolute immutability of complex objects? Commit to your answer.

Concept: Readonly only prevents reassignment of the property itself, but if the property holds an object, that object's internal state can still change unless it is also immutable.

data = $data; } } $data = new Data(); $data->value = 10; $container = new Container($data); $container->data->value = 20; // Allowed, internal mutation ?>

Result

The internal value changes from 10 to 20 despite readonly property

Knowing that readonly protects only the property reference, not the object's internal state, is crucial for designing truly immutable data structures.

Under the Hood

Readonly properties are enforced by PHP's engine at runtime. When a readonly property is assigned, PHP marks it as initialized and prevents any further assignments to that property on the same object instance. This check happens on every write attempt, throwing an error if violated. Internally, the property stores a flag indicating its readonly status and initialization state.

Why designed this way?

Readonly properties were introduced to provide a simple, language-level way to enforce immutability on object properties without requiring complex patterns or external libraries. Before PHP 8.1, developers had to rely on private properties with no setters or custom logic, which was error-prone and verbose. The design balances ease of use with performance by checking assignments at runtime only when necessary.

┌───────────────┐
│   Object      │
│ ┌───────────┐ │
│ │ Property  │ │
│ │ readonly? │─┼─Yes
│ └───────────┘ │
│       │       │
│       ▼       │
│  Is assigned? │
│       │       │
│   ┌───┴───┐   │
│   │ No    │   │
│   │ Assign│   │
│   └───────┘   │
│       │       │
│   ┌───┴───┐   │
│   │ Yes   │   │
│   │ Error │   │
│   └───────┘   │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Can you change a readonly property after the constructor finishes? Commit to yes or no.

Common Belief: Readonly properties can be changed anytime as long as you don't use the constructor.

Reality: Readonly properties can only be assigned once, typically during construction, and cannot be changed afterward.

Why it matters: Believing you can change readonly properties later leads to runtime errors and confusion when code breaks unexpectedly.

Quick: Does readonly mean the object held by the property is also immutable? Commit to yes or no.

Common Belief: Readonly means the entire object and its data cannot change once assigned.

Reality: Readonly only prevents changing the property reference; the object's internal data can still be modified unless it is also immutable.

Why it matters: Assuming full immutability causes bugs when internal state changes unexpectedly, breaking assumptions about data safety.

Quick: Can a child class override a readonly property as writable? Commit to yes or no.

Common Belief: Child classes can freely change readonly properties to writable if needed.

Reality: Readonly properties cannot be overridden as writable in subclasses; the readonly constraint is preserved.

Why it matters: Trying to override readonly as writable causes errors and breaks class inheritance contracts.

Quick: Are readonly properties a new feature in PHP 8.0? Commit to yes or no.

Common Belief: Readonly properties have been in PHP since version 8.0 or earlier.

Reality: Readonly properties were introduced in PHP 8.1, not earlier versions.

Why it matters: Using readonly syntax in earlier PHP versions causes syntax errors and confusion.

Expert Zone

1

Readonly properties only prevent reassignment of the property itself, not mutation of the object it references, so deep immutability requires immutable objects too.

2

Readonly properties can be combined with constructor property promotion for concise immutable class definitions.

3

Readonly properties are checked at runtime, so excessive use in performance-critical code might have minor overhead compared to normal properties.

When NOT to use

Avoid readonly properties when you need mutable state or when the property value must change after construction. Instead, use normal properties with controlled setters or immutable data structures for deep immutability.

Production Patterns

Readonly properties are commonly used in value objects, configuration objects, and data transfer objects to ensure data integrity. They simplify code by removing the need for explicit getters and setters while enforcing immutability.

Connections

Immutable data structures

Readonly properties build on the idea of immutability by enforcing fixed values at the property level.

Understanding readonly properties helps grasp how immutability can be enforced in programming languages to improve reliability.

Final keyword in object-oriented programming

Both readonly properties and final classes/methods prevent modification, but at different levels: properties vs. inheritance.

Knowing how readonly and final keywords restrict changes helps design safer, more predictable code.

Legal contracts

Readonly properties are like clauses in a contract that cannot be changed once signed.

Recognizing this connection clarifies why immutability is important for trust and correctness in software.

Common Pitfalls

#1 Trying to assign a readonly property outside the constructor.

Wrong approach:

name = "Alice"; // Error: Cannot assign outside constructor
$user->name = "Bob"; // Error
?>

Correct approach:

name = $name;
}
}
$user = new User("Alice");
// $user->name = "Bob"; // Still error
?>

Root cause:

Misunderstanding that readonly properties must be assigned during construction only.

#2 Assuming readonly means deep immutability of objects stored in properties.

Wrong approach:

data = $data;
}
}
$container = new Container(new Data());
$container->data->value = 5; // Allowed, unexpected
?>

Correct approach:

value = $value;
}
}
class Container {
public readonly ImmutableData $data;
public function __construct(ImmutableData $data) {
$this->data = $data;
}
}
$container = new Container(new ImmutableData(5));
// $container->data->value = 10; // Error
?>

Root cause:

Confusing readonly property assignment with immutability of the referenced object.

#3 Trying to override a readonly property as writable in a subclass.

Wrong approach:

id = $id;
}
}
class Child extends Base {
public int $id; // Error: Cannot override readonly property
}
?>

Correct approach:

id = $id;
}
}
class Child extends Base {
// No override of $id property
}
?>

Root cause:

Not knowing that readonly properties cannot be overridden as writable in subclasses.

Key Takeaways

Readonly properties in PHP allow you to set a property value once, usually during construction, and prevent any further changes.

They help make your objects more reliable by protecting important data from accidental modification.

Readonly only protects the property reference, not the internal state of objects stored in that property.

They were introduced in PHP 8.1 to simplify immutable object design without complex code.

Understanding readonly properties helps you write safer, clearer, and more maintainable PHP code.