Property Hooks RFC for PHP 8.4
A couple of days ago, I wrote about PHP 8.4 and what to expect. Well, I should have wait a bit longer to include big news: the Property Hooks RFC passed the vote and will likely get added to PHP 8.4. With an overwhelming 34 to 1 “yes” — which is clearly above the required 2/3 majority — Property Hooks will likely be part of the upcoming version for this winter.
What are Property Hooks?
Property Hooks and their syntax are inspired by languages like Kotlin, C# and Swift. The official RFC summarizes the proposal as follows:
“Developers often use methods to wrap and guard access to object properties. There are several highly common patterns for such logic, which in practice may be verbose to implement repeatedly. Alternatively, developers may use __get and __set to intercept reads and writes generically, but that is a sledge-hammer approach that intercepts all undefined (and some defined) properties unconditionally. Property hooks provide a more targeted, purpose-built tool for common property interactions…
This RFC introduces two “hooks” to override the default “get” and “set” behavior of a property. Although not included in this initial version, the design includes the ability to support more hooks in the future.“
So basically, Property Hooks should aim the goal of making developer life’s easier while writing/generating less boilerplate code. The proposal provides the following syntax:
class Loud
{
public string $name {
get {
return strtoupper($this->name);
}
}
}
$l = new Loud();
$l->name = 'larry'; // The stored value is "larry"
print $l->name; // prints "LARRY"This example does the following: $name is declared as public and does not need getters and setters anymore. Instead, whenever a value is set or retrieved (in this example: retrieve), the associated property hook is called. So basically, this means that $name will get uppercased before retrieved.
Apart of that, the RFC extends interface declaration in a way that properties and their hooks can get required too:
interface Named
{
// Objects implementing this interface must have a readable
// $fullName property. That could be satisfied with a traditional
// property or a property with a "get" hook.
public string $fullName { get; }
}
// The "User" class above satisfies this interface, but so does:
class SimpleUser implements Named
{
public function __construct(public readonly string $fullName) {}
}There is much more (detail) in this RFC but these two points summarise the purpose of Property Hooks very well.
Theory in Practice
I am a strong advocate of object oriented programming, not because I like it very much, but because I think it opens doors for sustainable, robust and reusable source code. I addressed this in Do Readonly Properties replace Getters (in PHP)?, and asked the question, whether the time of getters and setters are over. My conclusion was a hybrid approach since I wanted to expose interfaces to the public and hide concrete implementations. Because up until now, it was not possible to declare properties in interfaces, I recommended using getters/setters in order to not having empty interfaces for DTO’s, value objects or entities. I highly recommend reading Do Readonly Properties replace Getters (in PHP)? if you are interested in these topics.
But times change. Since the RFC includes declaring properties in interfaces, I think it is worth to give it a chance. I know that many programmers will have pain in the stomach juggling with properties publicly, but technically, the getters and setters are not away — they are just handled differently.
What do you think about Property Hooks? Are you going to use them? Let me know in the comments.
I am thinking about publishing my PHP blogs in video form. In these videos I would cover current topics around PHP, but also frameworks like Symfony, Lamins and Laravel as well as libraries from the community. Would you watch my videos? If yes, please let me know by hitting the “yes” button in the same blog post on my personal blog using the following link:
