On 08/05/2020 02:32, Mike Schinkel wrote:
1. The proposal on the table for Named Parameters effectively converts all parameters names into public aspects of the their function's API.
Yes, an opt-in version of named parameters might be useful. However, I'm not immediately convinced it should share any syntax with property promotion; the only real connection is that we're discussing them at the same time.
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.) 4. Who knows what syntax contortions will be required ... 5. New features for properties will likely take more discussion time to determine acceptable alternate syntaxes ...
The only reason I can think there would need to be variations in the syntax would be if there was some new syntax for properties which used commas in a way that would be ambiguous in parameter lists. Otherwise, parsing a promoted parameter is exactly the same as parsing a non-promoted one, but you stop at "," rather than ";".
3. The alternate block syntax would simplify userland refactoring to move properties to parameters and back... 11. The current Constructor Property Promotion adds complexity to the language where there is no analogue elsewhere PHP
By its nature, this proposed feature is merging two existing syntaxes. The current syntax proposal looks mostly like the constructor's existing parameter list; yours looks mostly like the existing property declarations; I'm not sure either is automatically better.
Switching to or from promoted properties will always require changing one or both parts of the class - the largest edit will be deleting or re-creating the body of the constructor.
6. Userland tooling would need to support both syntaxes... 7. Userland developers will be confused by and have to learn two slightly different syntaxes for essentially the same (type of) thing.
These points are both true no matter what the syntax looks like: it will be a new syntax, for a new feature, and tools and programmers will have to adapt to that. Glancing at the implementation on the RFC, the changes to the actual PHP parser actually seem fairly small.
8. I believe this alternate syntax addresses Michal Bruzuchalski's and Larry Garfield's concerns... 10. Nikita claims there is a "line" to be crossed when property declarations have their own blocks and would disallow their use with CPP...
I hesitate to speak for them, but I think their concerns are more conceptual: that this requires nesting a large portion of the class definition inside the constructor definition. Changing the syntax doesn't really change that - the "parameter block" would still be an extra level of nesting, attached to the constructor definition, rather than at the top level of the class, where it lives today.
9. This alternate syntax would reduce the desugaring required
The compiler won't need to transform the actual source code; the "de-sugaring" is just a representation of the _equivalent_ code if written manually.
PHP is primarily a line and block oriented language, and CPP purports to add Javascript-like complexity into a single statement.
I'm not sure what is "Javascript-like" about the proposed syntax, or why using semicolons rather than commas makes it less so.
Regards, -- Rowan Tommins (né Collins) [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
