> On May 7, 2020, at 4:47 AM, Rowan Tommins <rowan.coll...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
