On Fri, 8 Mar 2024, Larry Garfield wrote:
> Hi folks. Based on earlier discussions, we've made a number of
> changes to the RFC that should address some of the concerns people
> raised. We also had some very fruitful discussions off-list with
> several developers from the Foundation, which led to what we feel are
> some solid improvements.
>
> https://wiki.php.net/rfc/property-hooks
Some comments and questions:
Be aware, the detection logic works on $this->[propertyName] directly
at
compile time, not on dynamic forms of it like $prop = 'beep';
$this->$prop. That will not trigger a backing value.
How can that not cause issues?
The set hook's return type is unspecified, and will silently be
treated as void.
What happens if you *do* specify a return type? Will it Error?
Implicit ''set'' parameter
If the write-type of a property is the same as its defined type
(this is the common case), then the argument may be omitted
entirely.
…
If the parameter is not specified, it defaults to $value.
I am not a fan of this "magical" behaviour. Do we *need* this short cut,
and the following "Short-set"?
With asymmetric visibility that was previously proposed, the
example can be further simplified.
But it isn't here, so why is this example (and the next one) in the RFC?
:-)
Interaction with constructor property promotion
… In particular, the shorthand version of hook bodies and the
ability to call out to private methods if they get complicated
partially obviate the concern about syntactic complexity.
Although that is true, it *does* add more complexity in tools that needs
to parse PHP, as there is now another piece of new syntax that needs to
be added (and tested with).
ReflectionProperty has several new methods to work with hooks.
getHooks(): array returns an array of \ReflectionMethod objects
keyed by the hook they are for.
What will the name for the &get hook be? And shouldn't there be an enum
case for that as well?
cheers,
Derick
