On 10 April 2024 04:40:13 BST, Juliette Reinders Folmer
<php-internals_nos...@adviesenzo.nl> wrote:
* Whether a type can be specified on the parameter on `set` depends on whether
the property is typed. You cannot declare `set(mixed $value)` for an untyped
property, even though it would effectively be compatible. This is inconsistent
with the behaviour for, for instance method overloads, where this is
acceptable: https://3v4l.org/hbCor/rfc#vrfc.property-hooks , though it is
consistent with the behaviour of property overloads, where this is not
acceptable: https://3v4l.org/seDWM (anyone up for an RFC to fix this
inconsistency ?)
Just picking up on this point, because it's a bit of a tangle: PHP currently
makes a hard distinction between "typed properties" and "untyped properties".
For instance, unset() works differently, and the "readonly" attribute can only
be added to a typed property.
That's actually rather relevant to your point, because if this RFC passes we
would probably need to consider that PHP has at least 4 types of properties:
- dynamic properties (deprecated by default, but allowed with an attribute)
- declared but untyped properties
- typed properties
- virtual properties
But maybe 6, with:
- untyped properties with hooks
- typed properties with hooks
Of course, most of the time, users aren't aware of the current 3-way split, and
they won't need to think about all 6 of these variations. But there are going
to be cases where documentation or a future RFC has to cover edge cases of each.
I do think there is scope for removing some features from the RFC which are
nice but not essential, and reducing these combinations. For instance, if we
limit the access to the underlying property, we might be able to treat "virtual
properties" as just an optimisation: the engine doesn't allocate a property it
knows will never be accessed, and accesses to it, e.g. via reflection, just
return "uninitialized".
I am however conscious that RFCs have failed in the past for being "not
complete enough" as well as for being "too complex".
Regards,
Rowan Tommins
[IMSoP]
