Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123101
Message-ID: <e6e67a15-9e3d-4655-b870-519489bc1ffe@bastelstu.be>
Date: Wed, 10 Apr 2024 21:31:08 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC][Vote announcement] Property hooks
To: Arvids Godjuks <arvids.godjuks@gmail.com>,
 Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl>
Cc: internals@lists.php.net
References: <CAPyj-LBMQEJ=2BF=xk_on4O2xTU+MM2XRAZ5g=uPwVOf=bh+sw@mail.gmail.com>
 <66154AA0.1040905@adviesenzo.nl> <66160A1D.4060409@adviesenzo.nl>
 <CAL0xaBGbacGQuSOG0c0b7oeP=m5FMWRRYOqQjZ2FYwRK9ygaUA@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAL0xaBGbacGQuSOG0c0b7oeP=m5FMWRRYOqQjZ2FYwRK9ygaUA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

On 4/10/24 10:28, Arvids Godjuks wrote:
> The amount of complexity in these two hooks is on the level of the whole
> PHP OOP model with the number of footguns and WTF cases to rival magic
> quotes, register_globals=on and every other infamous gotcha we had in the
> engine that got deleted out of existence.

As someone who read the RFC like 20 times while it evolved (and just 
read it once more before submitting this email):

Most of what the RFC spells out explicitly, because that's what RFCs 
need to, is a pretty much natural consequence of how the existing PHP 
features work. You cannot really shorten the RFC without either making 
it underspecified or useless.

Is there some syntax that could technically be omitted? Sure. Would 
doing so meaningfully simplify the RFC? No, because most of the text 
length comes from the interaction of existing syntax and semantics with 
hooks and thus is an inherent property of property hooks (pun not 
intended). It's not the RFCs fault that references exist, or that 
casting an object to an array is legal, or whatever else needs to be 
explicitly spelled out.

I also believe that the chosen syntax fits nicely with the existing 
syntax, borrowing syntax where useful and inventing new syntax where the 
existing syntax does not provide anything.

It's a clear improvement over the status quo of __get() and __set(), 
especially from a third-party tooling perspective. I'm in favor.

Best regards
Tim Düsterhus