Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122616
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-251-g8332da0bf6-fm-20240305.001-g8332da0b
Precedence: bulk
MIME-Version: 1.0
Message-ID: <9b2dc2ae-bc00-4572-821f-08eaedf20a66@app.fastmail.com>
In-Reply-To: 
 <CA+hqhpe+6rkskveFO+OzesdbqVTwvrb2pRn+jjvmcTyz+AbZiQ@mail.gmail.com>
References: <fca97d6c-d4ec-4000-958a-72c32beb8421@app.fastmail.com>
 <CAJp_myUayeQ=irpFUG0OrUj=PjE3_mx395h_ARSdLmdyEB6_EQ@mail.gmail.com>
 <790b5b4e-f51b-4050-a12a-5fa903d0568f@app.fastmail.com>
 <CA+hqhpe5k0+qPezkgo9JdVyfmGan7DYPgmp7aGecSQokmArPiw@mail.gmail.com>
 <CA+hqhpe+6rkskveFO+OzesdbqVTwvrb2pRn+jjvmcTyz+AbZiQ@mail.gmail.com>
Date: Mon, 11 Mar 2024 17:44:20 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Mar 11, 2024, at 4:13 PM, Bruce Weirdan wrote:
> On Tue, Feb 27, 2024 at 6:22=E2=80=AFPM Bruce Weirdan <weirdan@gmail.c=
om> wrote:
>>
>> Hi Larry and others
>>
>> On Fri, Feb 23, 2024 at 12:57=E2=80=AFAM Larry Garfield <larry@garfie=
ldtech.com> wrote:
>> >
>> >
>> > I've added an FAQ section explaining why the Python/JS approach wou=
ldn't really work.  To be clear, Ilija and I spent 100+ hours doing rese=
arch and design before we started implementation (back in mid-late 2022)=
.  We did seriously consider the JS-style syntax, but in the end we foun=
d it created more problems than it solves.  For the type of language PHP=
 is (explicit typed properties), doing it on the property itself is a mu=
ch cleaner approach.
>>
>>
>> The section you added [1] seems to focus on having both `public string
>> $fistName` and `public function get/set firstName():string`, and how
>> it's hard to keep types and visibility in sync. But I'm not sure if
>> you considered making properties and accessors mutually exclusive. I
>> mean the following:
>>
>> ```php
>> class Person
>> {
>>     public string $firstName;      // compile time error, setter/gett=
er defined
>>
>>     public function __construct(private string $first, private string=
 $last) {}
>>
>>     public function get firstName(): string       // compile time
>> error, property defined
>>     {
>>         return $this->first . " " . $this->last;
>>     }
>>
>>     public function set firstName(string $value): void     // compile
>> time error, property defined
>>     {
>>         [$this->first, $this->last] =3D explode(' ', $value);
>>     }
>> }
>> ```
>>
>> This seems to address most of the counterpoints you listed, to some d=
egree:
>>
>> > What is the property type of the $firstName property?
>>
>> Well, you propose to allow wider write-types yourself, so the question
>> would apply there as well. But presumably, the property type is its
>> read type - so whatever getter returns.
>>
>> > but there's nothing inherent that forces, public string $firstName,=
 get firstName()s return and set firstName()s parameter to be the same. =
Even if we could detect it as a compile error, it means one more thing t=
hat the developer has to keep track of and get right, in three different=
 places.
>>
>> With mutually exclusive accessors and properties it becomes just two
>> places. And yes, accessor consistency would need to be checked at
>> compile time. But the same can be said for the widening of write type
>> you proposed.
>>
>> > What about visibility? Do the get/set methods need to have the same=
 visibility as the property?
>>
>> When there's no property the question becomes moot.
>>
>> > If not, does that become a way to do asymmetric visibility?
>>
>> Yes.
>>
>> > What about inconsistency between the method's visibility and the pr=
operty visibility? How is that handled?
>>
>> There's no inconsistency when there's no property. Accessor visibility
>> can be different - allowing the asymmetric visibility you wanted to
>> implement in your other RFC.
>>
>> > How do you differentiate between virtual and non-virtual properties?
>>
>> This one is hard to answer without asking another question: why would
>> you need to? Does the requirement to know it stem from engine
>> implementation details, or do you need as a person writing code in
>> PHP?
>>
>> > For non-virtual properties, if you need to triple-enter everything,=
 we're back to constructors pre-promotion. Plus, the accessor methods co=
uld be anywhere in the class, potentially hundreds of lines away. That m=
eans just looking at the property declaration doesn't tell you what its =
logic is; the logic may be on line 960, which only makes keeping its typ=
e/visibility in sync with the property harder.
>>
>> Forbidding property declaration reduces that to double. The rest is
>> mostly stylistic and can be said about traditional
>> (non-constructor-promoted) properties as well.
>>
>> Now this approach naturally has some open questions, foremost about
>> inheritance. But we probably don't need to go into those details if
>> you already explored this way and found some technical obstacles. If
>> you did, it would probably make sense to list them in the FAQ section.
>>
>> [1] https://wiki.php.net/rfc/property-hooks#why_not_pythonjavascript-=
style_accessor_methods
>
>
> Resending this since I've never got a reply and it's quite possible
> the message got lost due to mail list issues.

What you suggest might be possible, but it still runs into the problem o=
f backed properties.  Plain methods work fine for virtual properties, wh=
ich makes sense for Python and JS as they don't have pre-defined propert=
ies.  Once the language has predefined properties, a method-centric appr=
oach leaves a lot more to be manual, which makes it more work to achieve=
 the same end.  And then what if you want hooks on a property used in co=
nstructor promotion?  Or if you cannot declare a property and similarly =
named hook-method, how do you add hooks to a plain property in a child c=
lass, something generated code like ORMs will most likely want to do?

Even if it could be done, what would be the advantage?  Other than "it l=
ooks like JS", I don't really see any benefit, just a lot of complexity =
we'd have to sort out and find the edge cases on all over again, and bas=
ically rewrite the whole RFC.  Unless someone can show why the property-=
centric approach is fundamentally broken (and given that we have a succe=
ssful implementation already I think that is unlikely), there's little r=
eason to revisit the fundamentals of the RFC at this point.

(And, mind you, the above discussion does not demonstrate that a method-=
centric approach is in fact equally feasible.  At best, there are probab=
ly ways to make most things work, but without actually doing it there's =
no way to be sure it wouldn't run into a brick wall somewhere.)

--Larry Garfield