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.
class User { public string $name { set { if (strlen($value) === 0) { throw new ValueError("Name must be non-empty"); } $this->name = $value; } } public function __construct(string $name) { $this->name = $name; } }
You can play around with them on 3v4l.org
Late to the game here after it is all but guaranteed to pass, but I see this as a plus because it provides badly needed structure instead of magic __get()
and __set()
variables.
Looks like a good idea. first, I thought it will be too complicated for PHP to have this kind of syntax, but I've changed my mind, I think it will be amazing to have it in the language
use of the Value-Object seems better. "set" within a block of string doesn't look clean IMO.
like it
Though I'd prefer only allowing the syntax with parentheses like set($value)
I like it
Makes it more readable.
I do believe this has merit and uses cases, but I agree that value objects would cover this better and there are other things the developers could put their time towards
This RFC needs a re-work. While I support the idea, I don't think this is the right approach. The fact that the RFC is so long is a massive red flag. For example there are 4 different ways to define hooks:
class User { public string $username { set(string $value) { $this->username = strtolower($value); } } }
class User { public string $username { set(string $value) { $field = strtolower($value); } } }
class User { public string $username { set => strtolower($value); } }
class User { public function __construct( public string $username { set => strtolower($value); } ) {} }
Why?!
This is not what PHP needs.
I enjoy using set/get hooks in C# and strongly believe they are truly useful. Also, having them in interfaces is excellent!
Even if you won't use this yourselve, it will allow libraries and frameworks to do some really cool stuff. LGTM!
I've always envied C# developers for this feature in C#, I've been using __get() and __set() methods to achieve it
It's hard to read.
This RFC does not solve any issue, that cannot be solved right now with almost the same code, and makes the code harder to read. Beside this, this syntax invites developers to mix concerns.
Getters and setters are more and more considered bad : https://www.infoworld.com/article/2073723/why-getter-and-setter-methods-are-evil.html
This features feels like a C# fix applied on PHP which I don't like. We should focus on designing better classes, not fix a bad pattern.
This RFC proposes a way to have multi-line short closures — closures that don't need explicit use
statements, but can still have multiple lines and a return statement.
Interface Default Methods improves backwards compatibility when changing interfaces, but also add a way to have multi-inheritance in PHP.
Chain method on newly created objects without parentheses