Re: [RFC] Parameter Blocks (vs. Constructor Property Promotion and Named Parameters)

> On May 7, 2020, at 4:47 AM, Rowan Tommins <rowan.collins@gmail.com> wrote: > the current parser seems to handle it just fine. Interesting. You are correct on this point. I was going by memory that we had lots of problems with nested arrays, I should have tested this one assertion before posting. > I think you're solving a non-existent problem here. True, but that was only one of the several reasons I proposed the atlernate syntax, if you'll reread my original post you'll see the next point: 1. The proposal on the table for Named Parameters effectively converts all parameters names into public aspects of the their function's API. Some suggested allowing aliases, allowing OUT-OUT, but AFAIK there have been no suggestion for how to OPT-OUT of named parameters entirely. IOW, with the proposed syntax Named Parameters would infect every function/method across all of userland PHP code, whether the developer wants to maintain it as part of their API or not. This would be like PHP 8.0 making all private variable publicly accessible. This alternate syntax would make Named Parameters OPT-IN allowing developers to actively CHOOSE them — or not — as part of their public API. The rest were not part of my first email as I was trying to keep it shorter, but I now see my brevity was not effective as I had hoped, so... 2. Adding the ability to fully parse all features of properties and parameters into two different contexts each with their own syntax variants will add ongoing maintenance burden of core (or at least it seems apparent that it would.) 3. The alternate block syntax would simplify userland refactoring to move properties to parameters and back when compared to the RFC for CPP. Mostly (all?) it would require would be copying and pasting of lines. The RFC syntax would require at least a minimum amount of refactoring (semicolons to commas and back.) 4. Who knows what syntax contortions will be required for parameters as we try to apply new language features that affect properties? IOW, the current RFC is a less safe for future compatibility than the alternate block syntax. 5. New features for properties will likely take more discussion time to determine acceptable alternate syntaxes for using inside the parenthesis and then more time to implement, possibly delaying universally desired features or even nipping them in the bud. 6. Userland tooling would need to support both syntaxes, requiring more work for those project's maintainers, probably delay updates, and certainly requiring more ongoing maintenance. 7. Userland developers will be confused by and have to learn two slightly different syntaxes for essentially the same (type of) thing. 8. I believe this alternate syntax addresses Michal Bruzuchalski's and Larry Garfield's concerns, at least partially: https://externals.io/message/109335#109343 https://externals.io/message/109335#110024 9. This alternate syntax would reduce the desugaring required; only the value assignment would be needed: https://wiki.php.net/rfc/constructor_promotion#desugaring https://externals.io/message/109335#109515 10. Nikita claims there is a "line" to be crossed when property declarations have their own blocks and would disallow their use with CPP. And with the RFC's syntax that seems indeed an appropriate limitation. But with the alternate proposed syntax it would not need to be a limitation and I would argue that fewer limitations on future potential would be better. https://externals.io/message/109335#110034 And finally: 11. The current Constructor Property Promotion adds complexity to the language where there is no analogue elsewhere PHP, and having things "be like existing PHP" is a frequent argument related to new features on this list. PHP is primarily a line and block oriented language, and CPP purports to add Javascript-like complexity into a single statement. Frankly that is one of the reasons I so dislike programming in Javascript; I find the smaller distinct line-oriented statements of PHP much easier to reason about and would think many userland developers would also. The alternate syntax fits in with PHP's existing line- and block-oriented flavor much better the RFC's syntax. Simplicity (should) win(s). -Mike