Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123059
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>
Message-ID: <66154AA0.1040905@adviesenzo.nl>
Date: Tue, 9 Apr 2024 16:03:12 +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: <CAPyj-LBMQEJ=2BF=xk_on4O2xTU+MM2XRAZ5g=uPwVOf=bh+sw@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------030107090600060503060007"
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

This is a multi-part message in MIME format.
--------------030107090600060503060007
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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 of https://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

--------------030107090600060503060007
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">
    <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 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 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 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>
  </body>
</html>

--------------030107090600060503060007--