Enable it here
Property Hooks
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
All arguments against already mentioned. I also believe internally PHP could become slower, because of more complex parsing. Copying some open questions from another argument too: How should child classes behave? Are they overridable? How do you know if there is a setter behavior defined already? How should traits behave? Is there a way to call the parent class setter/getter? Would that be overriden or just called by default?
This is a much better approach than having to create getters and setters for validating values before assigning them to properties. Actually, this is an aspect from C# which I really like...
Getters and setters work just fine.
Additionally RFC says there is a large and obscure performance penalty for array typed properties and it's introduces additional complexity.
It feels like it adds a huge amount of complexity just to avoid getter/setter methods. Also, I'm not sure it's a good thing to lose the explicit differentiation between a property access and method call.
Note: setter methods are something I almost never use in the first place, since it's typically better to have immutable value objects.
This sounds pretty familiar to C# way for defining setters and getter. My problem with this RFC that it discourage code decoupling and separation of responsibilities. I know this is just an example use case, but an object shouldn't know how values should look like, it should be a responsibility of another component.
class User { private string $internalName; // Renamed to avoid conflict
public string $name {
set {
if (strlen($value) === 0) {
throw new ValueError("Name must be non-empty");
}
$this->internalName = $value; // Store the value in internalName
}
get {
return $this->internalName;
}
}
public function __construct(string $name) {
$this->name = $name;
}
}
The internal property used to store the value of $name is renamed to $internalName to avoid the conflict with the setter method, resolving the issue of the infinite loop. Error handling is improved by throwing a ValueError exception when an empty string is provided as the value for the name property. This ensures that validation errors are appropriately handled within the class.
This is well established in many other languages (Swift, Kotlin, C#) and the concerns of other commenters has not caused mass chaos as they would have you believe.
I'm not saying there aren't valid concerns, but the idea that "programmers will use it wrong" is not good enough.
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)
$value magically appearing is not good.
I like it
Makes it more readable.
Check out another RFCs
Chain method on newly created objects without parentheses
The "pipe operator" |> allows you to chain multiple function calls in a more convenient way.
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.