On Friday, 1 March 2024 at 06:28, Stephen Reay <php-li...@koalephant.com> wrote:
> For the third time: I'm well aware of how parameter types work everywhere > else, and that's why I'm asking why the same behaviour isn't being followed > here? > > - You've said you want to avoid boilerplate; and > - You've said you would expect most people to just use the implicit > `same-type $value` parameter; and > - You've acknowledged that the existing 'standard' is that a parameter > without a type is considered `mixed`; and > - You've acknowledged in your RFC that there is a use-case for wanting to > accept a wider type than what a property stores internally. > > So why then is it so unacceptable that the existing standard be followed, > such that a set hook with an "untyped" parameter would be treated as `mixed` > as it is everywhere else? > > Yes, I know you said "widening to `mixed` is unwise". I don't seem to recall > amongst all the type-related previous RFCs, any that suggested that child > parameters widening to `mixed` (either explicitly or implicitly) should be > deprecated, so I'm sorry but I don't see much value in that argument. Deprecating this behaviour would effectively mean, types are now required everywhere, which is an unreasonable proposition. The "implicit" widening to mixed is something that got introduced _after_ typing was introduced to PHP, and quite "late" even (in 7.2) considering typing objects/arrays has existed since PHP 5. [1] I don't think it's unreasonable that if property access hooks only work on typed properties, having no type means the type of the property and if you want to widen the type you _must_ specify a type. Especially if you want the backing type to be mixed well you are just required to write a typed property with type mixed, same as readonly. Best regards, Gina P. Banyard [1] https://wiki.php.net/rfc/parameter-no-type-variance
