On Wed, 10 Apr 2024 at 22:31, Tim Düsterhus <t...@bastelstu.be> wrote:
> 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 > Yeah we had a discussion with Larry on SF Slack, he made some things clear that it's either all or nothing, because once they dove in, it became clear that there's no way to gradually to introduce it. So, if it passes, the community is just gonna have to deal with the massive scope of it if they want the hooks or forget about them. -- Arvīds Godjuks +371 26 851 664 arvids.godj...@gmail.com Telegram: @psihius https://t.me/psihius
