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

Reply via email to