Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123080
Subject: Re: [PHP-DEV] [RFC][Vote announcement] Property hooks
To: internals@lists.php.net
References: <CAPyj-LBMQEJ=2BF=xk_on4O2xTU+MM2XRAZ5g=uPwVOf=bh+sw@mail.gmail.com>
 <66154AA0.1040905@adviesenzo.nl>
Message-ID: <66160A1D.4060409@adviesenzo.nl>
Date: Wed, 10 Apr 2024 05:40:13 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <66154AA0.1040905@adviesenzo.nl>
Content-Type: multipart/alternative;
 boundary="------------080507090208020004020306"
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

This is a multi-part message in MIME format.
--------------080507090208020004020306
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 9-4-2024 16:03, Juliette Reinders Folmer wrote:
> On 8-4-2024 23:39, Ilija Tovilo wrote:
>> Hi everyone
>>
>> Heads-up: Larry and I would like to start the vote of the property
>> hooks RFC tomorrow:
>> https://wiki.php.net/rfc/property-hooks
>>
>> We have worked long and hard on this RFC, and hope that we have found
>> some middle-ground that works for the majority. One last concern we
>> have not officially clarified on the list:
>>
>> https://externals.io/message/122445#122667
>>
>>>> I personally do not feel strongly about whether asymmetric types make it into the initial implementation. Larry does, however, and I think it is not fair to exclude them without providing any concrete reasons not to. [snip]
>>> My concern is more about the external impact of what is effectively a change to the type system of the language: [snip] will tools like PhpStan and Psalm require complex changes to analyse code using such properties?
>> In particular, this paragraph is referencing the ability to widen the
>> accepted $value parameter type of the set hook, described at the
>> bottom ofhttps://wiki.php.net/rfc/property-hooks#set. I have talked
>> to Ondřej Mirtes, the maintainer of PHPStan, and he confirmed that
>> this should not be complex to implement in PHPStan. In fact, PHPStan
>> already offers the @property-read and @property-write class
>> annotations, which can be used to describe "virtual" properties
>> handled within __get/__set, already providing asymmetric types of
>> sorts. Hence, this concern should be a non-issue.
>>
>> Thank you to everybody who has contributed to the discussion!
>>
>> Ilija
>>
>
> Ilija,
>
> Heads-up: I'm still writing up an opinion and intend to send it to the 
> list before end of day (CET). I know I'm late to the party, but I've 
> been having trouble finding the words to express myself properly 
> regarding this RFC (and have been struggling to find the right words 
> for months).
>
> Smile,
> Juliette

Later than intended, but here goes....

If there is one RFC which has been giving me nightmares since I first 
heard of it, it's this one.

I realize it is late in the discussion period to speak up, but for 
months I've been trying to find the words to express my concerns in a 
polite and constructive way and have failed.

I am going to try now anyway (before it is too late), so please bear 
with me. Also, as I'm not a C-developer, please forgive me if I get the 
internals wrong. I'm writing this from a PHP-dev/user perspective, with 
my perspective being heavily influenced by my role as maintainer of 
PHP_CodeSniffer.

---
TL;DR: this RFC tries to do too much in one go and introduces a huge 
amount of cognitive complexity with all the exceptions and the 
differences in behaviour between virtual and backed properties. This 
cognitive complexity is so high that I expect that the feature will 
catch most developers out a lot of the time.
---

I can definitely see the use case and desirability of the property hooks 
functionality proposed in the RFC and compared to the initial RFC I read 
last year, the current RFC is, IMO, much improved.
Huge kudos to Ilija and Larry for all the work they have put in to this!

I applaud the intention of this RFC to make it easier to avoid the magic 
__get()/__set() et al methods. What I have a problem with is the 
implementation details.

Over the last few years, we've seen a movement to get rid of more and 
more of the _surprising_ behaviour of PHP, with subtle exceptions being 
deprecated and slated for removal and (most) new syntaxes trying to use 
the principle of least surprise by design.

This RFC, in my view, is in stark contrast to this as it introduces a 
plethora of exceptions and subtle different behaviour in a way that will 
catch developers out for years to come.

At this moment (excluding property hooks), from a user perspective, 
there are three different function syntaxes in PHP: named functions (and 
methods), anonymous functions and arrow functions.

The semantics of these are very similar with subtle differences:
* Can be static or non-static.
* Take parameters, which can be typed, references, variadic, optional etc.
* Can have a return type.
* Can return by reference.
* Have a function "body".

The differences between the current syntaxes - from a user perspective - 
are as follows:
= Named functions:
* When declared in a class, can have visibility attached, can be 
abstract, can be final.
* When declared in an interface or declared as abstract, will not have a 
function "body".

= Anonymous functions:
* Can import plain variables from outside its scope with a `use()` clause.
* Are declared as an expression (can be assigned to a variable etc).

= Arrow functions:
* Have access to variables in the same scope.
* Are declared as an expression.
* Body of the function starts with a => instead of being enclosed in 
curlies and can end on a range of characters.
* Can only take one statement in the body.
* Automagically returns.

The property hooks RFC introduces a fourth flavour of function syntax. 
And not just one syntax, but five and the differences in the semantics 
of the function syntaxes are significant.

The differences in semantics I see for "full" property hook functions 
compared to other function syntaxes are as follows:
* `get` cannot take parameters (and doesn't have the parentheses 
typically expected for a function declaration).
* `get` cannot take return type (inherits this from the property, which 
is logically sound, but does create a syntactic difference).
* `set` can take one (typed or untyped) parameter.
* `set` cannot take return type (silently set to void, which is 
logically sound, but does create a syntactic difference).
* `set` magically creates a $value variable for the "new" value, though 
that variable _may_ have an arbitrary different name depending on 
whether or not the parameter was explicitly specified.
* Has a function body.

Then there are multiple short hand syntaxes, which each have yet more 
syntactic differences:
* The arrow function variant for `get` with all the above differences + 
the differences inherent to arrow functions, combined, with the 
exception of the access to variables in the same scope and a more 
clearly defined end of the expression.
* The implicit "set" parameter, which does not have a explicit 
parameter, does not have parentheses and has the magically created 
$value variable.
* The arrow function variant for `set` with all the above differences + 
the differences inherent to arrow functions with the above mentioned 
exceptions + the implicit assignment, which breaks the expected 
behaviour of arrow functions by assigning the result of the expression 
instead of returning it (totally understandable, but still a difference).
* The abstract/interface variants, which don't have a function body.

Next there are the differences in semantics which are now being 
introduced for properties:
* Aside from the hooks themselves....
* Properties _may_ or _may not_ have a default value anymore, depending 
on whether the hooks cause it to be a backed or a virtual property.
* Properties with hooks can _be_ readonly, but cannot be declared as 
readonly.

And then there are the new features for properties (not just hooked ones):
* Properties can now be declared as final.
* Properties can now be declared as abstract, but only with explicit 
hook requirements, otherwise the abstract keyword is not allowed.
* Properties can now be declared on interfaces, but only with explicit 
hook requirements, otherwise they are not allowed.
* Abstract/Interface properties don't comply with the same 
covariance/contravariance rules as other properties

And last but not least, there is the ability to declare property hooks 
in constructor property promotion ... where we can now basically have a 
function declaration within the signature of a method declaration.... 
with all five possible syntax types.

Additionally, when reading the RFC (in its current state), I see the 
following exceptions being put in place, which impact the semantics for 
properties:
* Only available for object properties, static properties are excluded.
* `var` for property declarations is not supported according to the RFC. 
While I 100% agree using the var keyword is old-school, using `var` 
effectively makes a property a public property (which would satisfy the 
visibility requirement for an interface/abstract class) and the `var` 
keyword is *not* deprecated, even though the RFC states it is: 
https://3v4l.org/3o50a
    I'd fully support formally deprecating the `var` keyword for 
properties and eventually removing it, but not supporting it for this 
RFC, even though it is still a supported language feature seems 
opinionated and arbitrary.
    Note: when testing the RFC code, declaring a property using the var 
keyword on an interface does not currently throw an error (while if it 
is not supported, I would expect one): 
https://3v4l.org/KaLqe/rfc#vrfc.property-hooks , same goes for using the 
var keyword with property hooks in a class: 
https://3v4l.org/mQ6pG/rfc#vrfc.property-hooks
* Disallows references to properties, but only when there is a set hook.
* Disallows indirect modification of a property, but only when there is 
a set hook.
* Write-only (virtual) properties, which cannot be read and you need to 
study the hook declaration in detail to figure out if a property is or 
is not write-only.
    Oh, and hang on, they *can* be read from a method in the same class 
as long as that method is called from within the set hook, so now the 
method will need to either do a backtrace or use Reflection to figure 
out whether it has access to the property value (now why does that 
remind me of the magic __...() methods ?).
* Readonly properties which are not denoted as readonly, but still are 
due to their virtual nature (get without access to $this->prop), which 
can only be figured out by, again, studying the contents of the hook 
function.
* 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 ?)
* Changes the meaning of `$this->property` read/write access for all 
methods called from within a hook while executing the hook.
* Creates two different flavour of properties: "backed" properties and 
"virtual" properties with significantly different behaviours, raising 
cognitive complexity.
     This includes, but is not limited to the fact that set hooks can be 
bypassed on virtual properties via a get reference.
* The range of different behaviours for various forms of serialization.

Furthermore:

[1] The RFC also states in "Interaction with isset() and unset()" that 
the behaviour of property hooks is consistent with how `isset()` 
interacts with `__get()` today. This is not true, as in: the behaviour 
as described for isset with magic methods is different than what the RFC 
states it is: https://3v4l.org/2Arkh/rfc#vrfc.property-hooks

Additionally, it proposes for isset() to throw an Error for virtual 
properties without a get hook. This is surprising behaviour as isset() 
by its nature is expected to *not* throw errors, but return false for 
whatever is not set or inaccessible from the current context: 
https://3v4l.org/3OlgM

[2] PHP supports "multi-property declarations", but I see no mention of 
these in the RFC, which makes it unclear if and if so, how property 
hooks would work with multi-property declarations.
class Foo {
     public string $bar, $baz, $bab;
}

[3] If a `set` hook gets a named parameter, is the magic `$value` 
variable still available or not ? I'd expect not, but it is unclear from 
the RFC.

[4] Why should ReflectionProperty::getRawValue() throw an error for 
static properties ? Instead of returning the value, identically to 
ReflectionProperty::getValue() ? This is surprising to me and I see no 
reason for it.


All in all, I really do see the use case for this feature and I most 
definitely appreciate all the work Ilija and Larry have put into the RFC 
and the implementation.

However, in its current state, I'm concerned that the feature introduces 
so many exceptional situations and WTF moments that it is a worse 
solution than the magic methods which are already available. (and no, 
I'm definitely not a fan of those magic methods either).

I think property hooks as currently proposed with all its catches will 
be hard to teach, will raise the barrier of entry to the language, can 
catch people out in dozens of different ways and introduces way too many 
peculiarities, while the tendency of the language has been to try to 
eliminate those kind of surprising behaviours.

Irrelevant side-note: I kind of feel like I could create a completely 
new "Why Equal doesn't Equal" Quiz just and only based on property hooks 
and people will still not get it afterwards.

---

As for the impact on static analysis tools....

I can't speak for other tools, but I can tell you that for 
PHP_CodeSniffer the impact of this RFC will be horrendous. Aside from 
the impact on the syntax recognition layer (Tokenizer), my rough 
estimate is that about 70% of all sniffs ever written will need to be 
adjusted for these five syntaxes and all the peculiarities around them - 
either to ignore hooks, work around hooks, skip over hooks, or to take 
hooks into account and examine them in all their variations.
I estimate it will take a good 5-6 years before all actively used sniffs 
will have been adjusted and that in the mean time, maintainers of both 
PHPCS itself as well as the popular external standards will have to deal 
with a significant number of extra support requests/bug reports related 
to this.

The sheer amount of new syntaxes which have been introduced starting 
with PHP 7.4, has already brought innovation in a large part of the 
PHP_CodeSniffer field to a near complete halt for the past four years as 
I'm continuously trying to play catch-up. This RFC will mean that 
innovation, like new PSR-5/19 Docs standards, QA sniffs for tests, 
significantly improving the Security standard etc, will all be put on 
hold for another few years while I have to deal with this change.

While I fully recognize that the impact on userland tooling is not a 
reason to reject a new PHP feature, nor should it be, I do believe that 
the impact of this RFC could be far less and easier to mitigate if 
different design choices were made or if the new syntaxes were 
introduced in a far slower, more staged approach across multiple PHP 
versions.

Smile,
Juliette

P.S.: nitpick: in the first two code examples under "Detailed 
Implementation" - "Set" the `$u` variable is missing the dollar sign for 
the `new User` line.

--------------080507090208020004020306
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 9-4-2024 16:03, Juliette Reinders Folmer wrote:<br>
    <blockquote cite="mid:66154AA0.1040905@adviesenzo.nl" type="cite">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      <div class="moz-cite-prefix">On 8-4-2024 23:39, Ilija Tovilo
        wrote:<br>
      </div>
      <blockquote
cite="mid:CAPyj-LBMQEJ=2BF=xk_on4O2xTU+MM2XRAZ5g=uPwVOf=bh+sw@mail.gmail.com"
        type="cite">
        <pre wrap="">Hi everyone

Heads-up: Larry and I would like to start the vote of the property
hooks RFC tomorrow:
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://wiki.php.net/rfc/property-hooks">https://wiki.php.net/rfc/property-hooks</a>

We have worked long and hard on this RFC, and hope that we have found
some middle-ground that works for the majority. One last concern we
have not officially clarified on the list:

<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://externals.io/message/122445#122667">https://externals.io/message/122445#122667</a>

</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">I personally do not feel strongly about whether asymmetric types make it into the initial implementation. Larry does, however, and I think it is not fair to exclude them without providing any concrete reasons not to. [snip]
</pre>
          </blockquote>
          <pre wrap="">My concern is more about the external impact of what is effectively a change to the type system of the language: [snip] will tools like PhpStan and Psalm require complex changes to analyse code using such properties?
</pre>
        </blockquote>
        <pre wrap="">In particular, this paragraph is referencing the ability to widen the
accepted $value parameter type of the set hook, described at the
bottom of <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://wiki.php.net/rfc/property-hooks#set">https://wiki.php.net/rfc/property-hooks#set</a>. I have talked
to Ondřej Mirtes, the maintainer of PHPStan, and he confirmed that
this should not be complex to implement in PHPStan. In fact, PHPStan
already offers the @property-read and @property-write class
annotations, which can be used to describe "virtual" properties
handled within __get/__set, already providing asymmetric types of
sorts. Hence, this concern should be a non-issue.

Thank you to everybody who has contributed to the discussion!

Ilija

</pre>
      </blockquote>
      <br>
      Ilija,<br>
      <br>
      Heads-up: I'm still writing up an opinion and intend to send it to
      the list before end of day (CET). I know I'm late to the party,
      but I've been having trouble finding the words to express myself
      properly regarding this RFC (and have been struggling to find the
      right words for months).<br>
      <br>
      Smile,<br>
      Juliette<br>
    </blockquote>
    <br>
    Later than intended, but here goes.... <br>
    <br>
    If there is one RFC which has been giving me nightmares since I
    first heard of it, it's this one.<br>
    <br>
    I realize it is late in the discussion period to speak up, but for
    months I've been trying to find the words to express my concerns in
    a polite and constructive way and have failed.<br>
    <br>
    I am going to try now anyway (before it is too late), so please bear
    with me. Also, as I'm not a C-developer, please forgive me if I get
    the internals wrong. I'm writing this from a PHP-dev/user
    perspective, with my perspective being heavily influenced by my role
    as maintainer of PHP_CodeSniffer.<br>
    <br>
    ---<br>
    TL;DR: this RFC tries to do too much in one go and introduces a huge
    amount of cognitive complexity with all the exceptions and the
    differences in behaviour between virtual and backed properties. This
    cognitive complexity is so high that I expect that the feature will
    catch most developers out a lot of the time.<br>
    ---<br>
    <br>
    I can definitely see the use case and desirability of the property
    hooks functionality proposed in the RFC and compared to the initial
    RFC I read last year, the current RFC is, IMO, much improved.<br>
    Huge kudos to Ilija and Larry for all the work they have put in to
    this!<br>
    <br>
    I applaud the intention of this RFC to make it easier to avoid the
    magic __get()/__set() et al methods. What I have a problem with is
    the implementation details.<br>
    <br>
    Over the last few years, we've seen a movement to get rid of more
    and more of the _surprising_ behaviour of PHP, with subtle
    exceptions being deprecated and slated for removal and (most) new
    syntaxes trying to use the principle of least surprise by design.<br>
    <br>
    This RFC, in my view, is in stark contrast to this as it introduces
    a plethora of exceptions and subtle different behaviour in a way
    that will catch developers out for years to come.<br>
    <br>
    At this moment (excluding property hooks), from a user perspective,
    there are three different function syntaxes in PHP: named functions
    (and methods), anonymous functions and arrow functions.<br>
    <br>
    The semantics of these are very similar with subtle differences:<br>
    * Can be static or non-static.<br>
    * Take parameters, which can be typed, references, variadic,
    optional etc.<br>
    * Can have a return type.<br>
    * Can return by reference.<br>
    * Have a function "body".<br>
    <br>
    The differences between the current syntaxes - from a user
    perspective - are as follows:<br>
    = Named functions:<br>
    * When declared in a class, can have visibility attached, can be
    abstract, can be final.<br>
    * When declared in an interface or declared as abstract, will not
    have a function "body".<br>
    <br>
    = Anonymous functions:<br>
    * Can import plain variables from outside its scope with a `use()`
    clause.<br>
    * Are declared as an expression (can be assigned to a variable etc).<br>
    <br>
    = Arrow functions:<br>
    * Have access to variables in the same scope.<br>
    * Are declared as an expression.<br>
    * Body of the function starts with a =&gt; instead of being enclosed
    in curlies and can end on a range of characters.<br>
    * Can only take one statement in the body.<br>
    * Automagically returns.<br>
    <br>
    The property hooks RFC introduces a fourth flavour of function
    syntax. And not just one syntax, but five and the differences in the
    semantics of the function syntaxes are significant.<br>
    <br>
    The differences in semantics I see for "full" property hook
    functions compared to other function syntaxes are as follows:<br>
    * `get` cannot take parameters (and doesn't have the parentheses
    typically expected for a function declaration).<br>
    * `get` cannot take return type (inherits this from the property,
    which is logically sound, but does create a syntactic difference).<br>
    * `set` can take one (typed or untyped) parameter.<br>
    * `set` cannot take return type (silently set to void, which is
    logically sound, but does create a syntactic difference).<br>
    * `set` magically creates a $value variable for the "new" value,
    though that variable _may_ have an arbitrary different name
    depending on whether or not the parameter was explicitly specified.<br>
    * Has a function body.<br>
    <br>
    Then there are multiple short hand syntaxes, which each have yet
    more syntactic differences:<br>
    * The arrow function variant for `get` with all the above
    differences + the differences inherent to arrow functions, combined,
    with the exception of the access to variables in the same scope and
    a more clearly defined end of the expression.<br>
    * The implicit "set" parameter, which does not have a explicit
    parameter, does not have parentheses and has the magically created
    $value variable.<br>
    * The arrow function variant for `set` with all the above
    differences + the differences inherent to arrow functions with the
    above mentioned exceptions + the implicit assignment, which breaks
    the expected behaviour of arrow functions by assigning the result of
    the expression instead of returning it (totally understandable, but
    still a difference).<br>
    * The abstract/interface variants, which don't have a function body.<br>
    <br>
    Next there are the differences in semantics which are now being
    introduced for properties:<br>
    * Aside from the hooks themselves....<br>
    * Properties _may_ or _may not_ have a default value anymore,
    depending on whether the hooks cause it to be a backed or a virtual
    property.<br>
    * Properties with hooks can _be_ readonly, but cannot be declared as
    readonly.<br>
    <br>
    And then there are the new features for properties (not just hooked
    ones):<br>
    * Properties can now be declared as final.<br>
    * Properties can now be declared as abstract, but only with explicit
    hook requirements, otherwise the abstract keyword is not allowed.<br>
    * Properties can now be declared on interfaces, but only with
    explicit hook requirements, otherwise they are not allowed.<br>
    * Abstract/Interface properties don't comply with the same
    covariance/contravariance rules as other properties<br>
    <br>
    And last but not least, there is the ability to declare property
    hooks in constructor property promotion ... where we can now
    basically have a function declaration within the signature of a
    method declaration.... with all five possible syntax types.<br>
    <br>
    Additionally, when reading the RFC (in its current state), I see the
    following exceptions being put in place, which impact the semantics
    for properties:<br>
    * Only available for object properties, static properties are
    excluded.<br>
    * `var` for property declarations is not supported according to the
    RFC. While I 100% agree using the var keyword is old-school, using
    `var` effectively makes a property a public property (which would
    satisfy the visibility requirement for an interface/abstract class)
    and the `var` keyword is *not* deprecated, even though the RFC
    states it is: <a class="moz-txt-link-freetext"
      href="https://3v4l.org/3o50a">https://3v4l.org/3o50a</a><br>
       I'd fully support formally deprecating the `var` keyword for
    properties and eventually removing it, but not supporting it for
    this RFC, even though it is still a supported language feature seems
    opinionated and arbitrary.<br>
       Note: when testing the RFC code, declaring a property using the
    var keyword on an interface does not currently throw an error (while
    if it is not supported, I would expect one): <a
      class="moz-txt-link-freetext"
      href="https://3v4l.org/KaLqe/rfc#vrfc.property-hooks"><a class="moz-txt-link-freetext" href="https://3v4l.org/KaLqe/rfc#vrfc.property-hooks">https://3v4l.org/KaLqe/rfc#vrfc.property-hooks</a></a>
    , same goes for using the var keyword with property hooks in a
    class: <a class="moz-txt-link-freetext"
      href="https://3v4l.org/mQ6pG/rfc#vrfc.property-hooks">https://3v4l.org/mQ6pG/rfc#vrfc.property-hooks</a><br>
    * Disallows references to properties, but only when there is a set
    hook.<br>
    * Disallows indirect modification of a property, but only when there
    is a set hook.<br>
    * Write-only (virtual) properties, which cannot be read and you need
    to study the hook declaration in detail to figure out if a property
    is or is not write-only.<br>
       Oh, and hang on, they *can* be read from a method in the same
    class as long as that method is called from within the set hook, so
    now the method will need to either do a backtrace or use Reflection
    to figure out whether it has access to the property value (now why
    does that remind me of the magic __...() methods ?).<br>
    * Readonly properties which are not denoted as readonly, but still
    are due to their virtual nature (get without access to
    $this-&gt;prop), which can only be figured out by, again, studying
    the contents of the hook function.<br>
    * 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: <a
      class="moz-txt-link-freetext"
      href="https://3v4l.org/hbCor/rfc#vrfc.property-hooks"><a class="moz-txt-link-freetext" href="https://3v4l.org/hbCor/rfc#vrfc.property-hooks">https://3v4l.org/hbCor/rfc#vrfc.property-hooks</a></a>
    , though it is consistent with the behaviour of property overloads,
    where this is not acceptable: <a class="moz-txt-link-freetext"
      href="https://3v4l.org/seDWM">https://3v4l.org/seDWM</a> (anyone
    up for an RFC to fix this inconsistency ?)<br>
    * Changes the meaning of `$this-&gt;property` read/write access for
    all methods called from within a hook while executing the hook.<br>
    * Creates two different flavour of properties: "backed" properties
    and "virtual" properties with significantly different behaviours,
    raising cognitive complexity.<br>
        This includes, but is not limited to the fact that set hooks can
    be bypassed on virtual properties via a get reference.<br>
    * The range of different behaviours for various forms of
    serialization.<br>
    <br>
    Furthermore:<br>
    <br>
    [1] The RFC also states in "Interaction with isset() and unset()"
    that the behaviour of property hooks is consistent with how
    `isset()` interacts with `__get()` today. This is not true, as in:
    the behaviour as described for isset with magic methods is different
    than what the RFC states it is: <a class="moz-txt-link-freetext"
      href="https://3v4l.org/2Arkh/rfc#vrfc.property-hooks">https://3v4l.org/2Arkh/rfc#vrfc.property-hooks</a><br>
    <br>
    Additionally, it proposes for isset() to throw an Error for virtual
    properties without a get hook. This is surprising behaviour as
    isset() by its nature is expected to *not* throw errors, but return
    false for whatever is not set or inaccessible from the current
    context: <a class="moz-txt-link-freetext"
      href="https://3v4l.org/3OlgM">https://3v4l.org/3OlgM</a><br>
    <br>
    [2] PHP supports "multi-property declarations", but I see no mention
    of these in the RFC, which makes it unclear if and if so, how
    property hooks would work with multi-property declarations.<br>
    class Foo {<br>
        public string $bar, $baz, $bab;<br>
    }<br>
    <br>
    [3] If a `set` hook gets a named parameter, is the magic `$value`
    variable still available or not ? I'd expect not, but it is unclear
    from the RFC.<br>
    <br>
    [4] Why should ReflectionProperty::getRawValue() throw an error for
    static properties ? Instead of returning the value, identically to
    ReflectionProperty::getValue() ? This is surprising to me and I see
    no reason for it.<br>
    <br>
    <br>
    All in all, I really do see the use case for this feature and I most
    definitely appreciate all the work Ilija and Larry have put into the
    RFC and the implementation.<br>
    <br>
    However, in its current state, I'm concerned that the feature
    introduces so many exceptional situations and WTF moments that it is
    a worse solution than the magic methods which are already available.
    (and no, I'm definitely not a fan of those magic methods either).<br>
    <br>
    I think property hooks as currently proposed with all its catches
    will be hard to teach, will raise the barrier of entry to the
    language, can catch people out in dozens of different ways and
    introduces way too many peculiarities, while the tendency of the
    language has been to try to eliminate those kind of surprising
    behaviours.<br>
    <br>
    Irrelevant side-note: I kind of feel like I could create a
    completely new "Why Equal doesn't Equal" Quiz just and only based on
    property hooks and people will still not get it afterwards.<br>
    <br>
    ---<br>
    <br>
    As for the impact on static analysis tools....<br>
    <br>
    I can't speak for other tools, but I can tell you that for
    PHP_CodeSniffer the impact of this RFC will be horrendous. Aside
    from the impact on the syntax recognition layer (Tokenizer), my
    rough estimate is that about 70% of all sniffs ever written will
    need to be adjusted for these five syntaxes and all the
    peculiarities around them - either to ignore hooks, work around
    hooks, skip over hooks, or to take hooks into account and examine
    them in all their variations.<br>
    I estimate it will take a good 5-6 years before all actively used
    sniffs will have been adjusted and that in the mean time,
    maintainers of both PHPCS itself as well as the popular external
    standards will have to deal with a significant number of extra
    support requests/bug reports related to this.<br>
    <br>
    The sheer amount of new syntaxes which have been introduced starting
    with PHP 7.4, has already brought innovation in a large part of the
    PHP_CodeSniffer field to a near complete halt for the past four
    years as I'm continuously trying to play catch-up. This RFC will
    mean that innovation, like new PSR-5/19 Docs standards, QA sniffs
    for tests, significantly improving the Security standard etc, will
    all be put on hold for another few years while I have to deal with
    this change.<br>
    <br>
    While I fully recognize that the impact on userland tooling is not a
    reason to reject a new PHP feature, nor should it be, I do believe
    that the impact of this RFC could be far less and easier to mitigate
    if different design choices were made or if the new syntaxes were
    introduced in a far slower, more staged approach across multiple PHP
    versions.<br>
    <br>
    Smile,<br>
    Juliette<br>
    <br>
    P.S.: nitpick: in the first two code examples under "Detailed
    Implementation" - "Set" the `$u` variable is missing the dollar sign
    for the `new User` line.<br>
  </body>
</html>

--------------080507090208020004020306--