Re: [RFC][Vote announcement] Property hooks

On 10 April 2024 04:40:13 BST, Juliette Reinders Folmer <php-internals_nospam@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]