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

> On May 6, 2020, at 4:14 PM, Rowan Tommins <rowan.collins@gmail.com> wrote: > > Hi Mike, > > On 06/05/2020 20:48, Mike Schinkel wrote: >> Consider simply what we might call "Parameter Blocks." Since PHP always expects >> a parentheses to follow the function or method name it should be possible to opt-in replace it with >> a brace-enclosed block of parameters instead since it would be unambiguous and this no conflict, and >> no need for new keywords. >> >> The following illustrates how it my be used by repurposing an example from the RFC: >> ... > > > I'm not really clear what this example is showing. It seems to be the same as the one in > Nikita's RFC, but with the punctuation changed slightly from "(public $foo, public > $bar)" to "{public $foo; public $bar;}" That is exactly the case. > I'm not sure how this changes anything, or how it relates to named parameters. Could you > expand on the problems you see this solving? Let's look at it like this, with line numbers that would be reported in the case of syntax error: 1: function foo(public $foo, public $bar) {} vs. 1: function foo { 2: public $foo; 3: public $bar; 4: } {} -------------- Now, consider the following two examples. On which line would PHP report the error? function foo() ( public $foo, public $ bar ) {} vs. function foo { public $foo; public $ bar; } {} With two parameters, no attributes and no PHP doc the error is pretty easy to spot. ----------------- Now consider a constructor w/20 properties/parameters, 5 attributes across those properties, and a total of 100 lines of PHP Doc interspersed and it becomes a lot more difficult to deal with if it is one virtual line — as PHP sees it — than spread across 125 lines. Much harder to diagnose a syntax error. ----------------- It is for the same reason I avoid code that instantiates a single array literal that spans hundreds of line of code and instead create methods to append small array literals to the array. If you have one really long virtual line it makes it much harder to identify where syntax errors occurred. Having one long virtual line also limits what features can be added in future versions of PHP. If you need help visualizing it I mocked up an example from actual function that is in product that was written by someone else before I joined the client's current team: https://gist.github.com/mikeschinkel/faaee3fc8ccc2371c7200f3d634289c4 <https://gist.github.com/mikeschinkel/faaee3fc8ccc2371c7200f3d634289c4> -Mike