Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110090
To: PHP internals <internals@lists.php.net>
References: <CAF+90c8tW27-rhrk8pLieMsEWa4WHEBciPX1zThME68zf6s2QQ@mail.gmail.com>
 <1C09C0A9-1DA4-4753-8E5A-A739D52DA0B3@newclarity.net>
 <54c5f8f0-1526-53df-0912-0b00e0e54bc3@gmail.com>
 <44B0AB58-2993-403F-B75C-124AB26B6875@newclarity.net>
 <CALKiJKoX+J2YD7Aqxut145f9dYka7XpykBZLdhcM5z-yX4PU4Q@mail.gmail.com>
 <CD7E6018-8678-4CBE-B5CD-F7C3E1925BD6@newclarity.net>
Message-ID: <d0d91368-92ec-3f00-dd22-faed08b0ccf4@gmail.com>
Date: Fri, 8 May 2020 19:04:21 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <CD7E6018-8678-4CBE-B5CD-F7C3E1925BD6@newclarity.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [RFC] Parameter Blocks (vs. Constructor Property
 Promotion and Named Parameters)
From: rowan.collins@gmail.com (Rowan Tommins)

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]