Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110060
MIME-Version: 1.0
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>
In-Reply-To: <44B0AB58-2993-403F-B75C-124AB26B6875@newclarity.net>
Date: Thu, 7 May 2020 09:47:14 +0100
Message-ID: <CALKiJKoX+J2YD7Aqxut145f9dYka7XpykBZLdhcM5z-yX4PU4Q@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000001ba71205a50aee88"
Subject: Re: [PHP-DEV] [RFC] Parameter Blocks (vs. Constructor Property
 Promotion and Named Parameters)
From: rowan.collins@gmail.com (Rowan Tommins)

--0000000000001ba71205a50aee88
Content-Type: text/plain; charset="UTF-8"

On Wed, 6 May 2020 at 22:48, Mike Schinkel <mike@newclarity.net> wrote:

> 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;
> } {}
>
>

This feels like an implementation detail of the parser, rather than an
automatic consequence of the syntax, and the current parser seems to handle
it just fine.

<?php
function foo(
    $foo,
    $ bar
) {}
# unexpected '$', expecting variable... on line 4
# https://3v4l.org/AC9kh

The same is true of arrays: both syntax and run-time errors are reported
with correct line numbers, e.g. https://3v4l.org/fMp4t and
https://3v4l.org/BXO8q




> 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
>


Here's the single-declaration version of that with a syntax error on line
163: https://3v4l.org/mGq2f

I think you're solving a non-existent problem here.

Regards,
-- 
Rowan Tommins
[IMSoP]

--0000000000001ba71205a50aee88--