Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105193
MIME-Version: 1.0
References: <CAF+90c9YZcrquGfS4h3x1a+codkCFLarAThsOXcN69RCTvbAFA@mail.gmail.com>
 <CAF+90c_keZTbMTuDO+9WRa53MsYxbNxkMO_pxGyymGnxCp691g@mail.gmail.com>
 <582b57dc-42a0-582b-9471-2ede97ba584a@telia.com> <CAF+90c-1uw-iuW9DAp4jukRehmZ11x=qMAEsAfEXEs5-A-pbig@mail.gmail.com>
In-Reply-To: <CAF+90c-1uw-iuW9DAp4jukRehmZ11x=qMAEsAfEXEs5-A-pbig@mail.gmail.com>
Date: Wed, 10 Apr 2019 09:39:10 +0100
Message-ID: <CALKiJKoYwkrJdFbLCbLWTftDmPWSzZYS8AW3+WCG7+ny+g2mFg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000008f356c05862901fc"
Subject: Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
From: rowan.collins@gmail.com (Rowan Collins)

--0000000000008f356c05862901fc
Content-Type: text/plain; charset="UTF-8"

On Tue, 9 Apr 2019 at 11:20, Nikita Popov <nikita.ppv@gmail.com> wrote:

> The ==> syntax is the other one I implemented (
> https://github.com/php/php-src/pull/3945). The implementation is based on
> lexer lookahead, which is ugly but still manageable. I haven't seen much
> support for this variant in this discussion though. And of course, if
> there's no strong preference for ==>, I'd rather go with the variant that
> is easier for us (and all 3rd party tooling) to support from a technical
> perspective.
>


I'd just like to amplify this mention of 3rd party tooling: if we go with
something which requires complex lexer/parser rules, then every editor,
IDE, and static analysis tool will need to also work with that syntax.

For those saying they "slightly prefer" ==> please ask yourself, do you
prefer it enough to add complexity to every tool that wants to process PHP
source code?

Regards,
-- 
Rowan Collins
[IMSoP]

--0000000000008f356c05862901fc--