Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88399
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.213.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <BLU436-SMTP156E8D7D141A710541FCA0FE2450@phx.gbl>
References: <BLU436-SMTP156E8D7D141A710541FCA0FE2450@phx.gbl>
Date: Tue, 22 Sep 2015 11:25:46 +0300
Message-ID: <CA+9eiLtfxLNCMra1Xj9PEhAFZB+h903AK1rmWSQAH4SqQm2qCQ@mail.gmail.com>
To: Bob Weinand <bobwei9@hotmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11415a8ea4c6f8052051be2d
Subject: Re: [PHP-DEV] [RFC] [VOTE] Short Closures
From: dmitry@zend.com (Dmitry Stogov)

--001a11415a8ea4c6f8052051be2d
Content-Type: text/plain; charset=UTF-8

I'm against the magic - "automatically use () all of the (compiled)
variables".
I'm also against compound short closures with curly brackets.
in my opinion they opens too many ambiguous questions.

function foo() {
  (($x) ~> {$y = 3; return $y + $x;})(5);
  return $y;
}

also think about nested closures and use of variables from not direct
enclosure.

I'm not sure if we need all "functional programming" features in PHP, but
if we introduce them, lets do it consistently with the existing language.
I think, this proposal can't be approved without support for type hinting.

Thanks. Dmitry.

On Tue, Sep 22, 2015 at 4:59 AM, Bob Weinand <bobwei9@hotmail.com> wrote:

> Hey,
>
> Thanks for all your feedback in the discussion thread!
>
> So, before I start the vote, just two quick notes:
> I've added two notes about the statement syntax and the single variable
> use.
> Though a few people complained, I'm not switching to the ==> operator, as
> I noticed many people expected typehints to work (they don't due to parser
> limitations) when they compared to Hack's short Closures. It also allows us
> to differ syntax-wise [e.g. for typehints] from Hack without causing any
> confusion later. Which should be the smartest choice: Avoid conflicts. (If
> anyone strongly feels against that, he may vote no, but I would like to not
> bikeshed that in this Vote thread, but leave it free for eventual actual
> issues.)
>
> Now, the link to the RFC about Short Closures:
> https://wiki.php.net/rfc/short_closures
> or straight ahead to the vote:
> https://wiki.php.net/rfc/short_closures#vote
>
> Thanks,
> Bob
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a11415a8ea4c6f8052051be2d--