Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110052
Message-ID: <44B0AB58-2993-403F-B75C-124AB26B6875@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_7203CE63-2ED2-4182-9F82-E2D40C4BF4DB"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 6 May 2020 17:48:20 -0400
In-Reply-To: <54c5f8f0-1526-53df-0912-0b00e0e54bc3@gmail.com>
Cc: internals@lists.php.net
To: Rowan Tommins <rowan.collins@gmail.com>
References: <CAF+90c8tW27-rhrk8pLieMsEWa4WHEBciPX1zThME68zf6s2QQ@mail.gmail.com>
 <1C09C0A9-1DA4-4753-8E5A-A739D52DA0B3@newclarity.net>
 <54c5f8f0-1526-53df-0912-0b00e0e54bc3@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Parameter Blocks (vs. Constructor Property
 Promotion and Named Parameters)
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_7203CE63-2ED2-4182-9F82-E2D40C4BF4DB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On May 6, 2020, at 4:14 PM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> Hi Mike,
>=20
> 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.
>>=20
>> The following illustrates how it my be used by repurposing an example =
from the RFC:
>> ...
>=20
>=20
> 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.=20

1: function foo {
2:	public $foo;=20
3: 	public $bar;
4: } {}

--------------

Now, consider the following two examples. On which line would PHP report =
the error?

function foo() (
	public $foo,=20
	public $ bar
) {}

vs.=20

function foo {
	public $foo;=20
 	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 =E2=80=94 as PHP sees it =E2=80=94 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=

--Apple-Mail=_7203CE63-2ED2-4182-9F82-E2D40C4BF4DB--