PHP 8.4 introduced several improvements, but one of the most interesting changes to the language’s object-oriented model is Property Hooks. At first glance, many developers focus on the obvious benefit: reducing the need for repetitive getters and setters. However, there is a less talked-about feature hidden inside this addition that I find particularly exciting, the ability to define properties directly in interfaces.
For a long time, PHP interfaces could only enforce methods. If you wanted to guarantee that a class exposed certain data, you had to do it indirectly through method contracts like getName() or setName(). The language itself had no way to enforce that a class must contain a specific public property. With property hooks in PHP 8.4, that limitation finally disappears.
Properties as Interface Contracts
Property hooks allow interfaces to define properties that implementing classes must provide. In practice, this means an interface can now declare that a property exists and describe how it can be accessed.
For example:
interface UserInterface
{
public string $name { get; }
}This declaration tells PHP that any class implementing UserInterface must provide a readable $name property. If a class claims to implement the interface but does not define that property, the interpreter will raise a fatal error. The property requirement becomes part of the contract, just like any abstract method would be.
This change may look small, but it fundamentally expands what interfaces can express.
Strict Enforcement by the Interpreter
When a class fails to implement the property defined in the interface, PHP enforces the rule immediately.
class User implements UserInterface
{
// Fatal error: Class User must implement the remaining
// method (UserInterface::$name::get)
}The error message may look a bit unusual at first because the hook internally behaves similarly to an abstract accessor method. Still, the idea is clear: the contract defined by the interface must be satisfied.
Implementing the Property
To satisfy the interface requirement, the implementing class simply needs to define the property or provide its own hook implementation.
The most straightforward implementation looks like this:
class User implements UserInterface
{
public string $name;
}This works because the class now exposes a public property that fulfills the interface’s requirement. Alternatively, developers can implement custom hooks if they want more control over how the property behaves internally.
Why This Matters
The ability to define properties in interfaces introduces a new level of expressiveness to PHP’s type system. In some cases, forcing developers to use getters and setters created unnecessary boilerplate when the real requirement was simply “this object must expose this piece of data.”
Now the language allows that intention to be stated directly.
This also opens interesting possibilities for designing domain models where properties are part of the public contract rather than hidden behind accessor methods.
The End of Getters and Setters?
Whether property hooks will truly replace traditional getters and setters remains to be seen. In many cases, explicit methods still make sense, especially when additional logic is required or when the public API should remain stable even if internal data structures change.
However, property hooks give developers a new option. Instead of automatically generating getters and setters for every field, we can decide whether a property should behave like a simple value or a controlled interface.
Sometimes the simplest design is also the clearest.
Final Thoughts
Property hooks are more than just syntactic sugar. They represent a meaningful step forward in PHP’s object model, allowing interfaces to describe data contracts more naturally.
Whether this becomes the beginning of the end for boilerplate getters and setters, or simply another tool that developers occasionally use, it is definitely one of the more intriguing features introduced in PHP 8.4.
I’m curious how others plan to use this. Is this the start of a cleaner approach to interfaces, or just another opportunity for developers to over-engineer their abstractions?