On Tue, Sep 22, 2015 at 7:01 PM, Bob Weinand <bobw...@hotmail.com> wrote:
>
> > Am 22.09.2015 um 17:36 schrieb Dmitry Stogov <dmi...@zend.com>:
> >
> > On Tue, Sep 22, 2015 at 4:54 PM, Joe Watkins <pthre...@pthreads.org>
> wrote:
> >
> >> I'd really like to understand what you're trying to say there Dmitry,
> but
> >> I don't get it.
> >>
> >> What is your example function trying to show ?
> >>
> >> As it mentions in the RFC, vars in short closure are by-value, so I
> can't
> >> see what side effects you might be thinking of ?
> >>
> >
> > It's clear to me that foo() will return NULL, but how many warnings about
> > unused variable $y will we get?
> >
> > Thanks. Dmitry.
> >
> >
> >>
> >> Cheers
> >> Joe
> >>
> >> On Tue, Sep 22, 2015 at 9:25 AM, Dmitry Stogov <dmi...@zend.com> wrote:
> >>
> >>> 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 <bobw...@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
>
>
> Notice: Undefined variable: y in php shell code on line 3
>
> It just yields exactly one notice about the inexistent $y (as it obviously
> does not leak through the scope): by-value binding.
>
> I'm not sure what your issue here is?
>
The current PHP version emits two warning on similar constructs, and this
is explainable because we explicitly "use" $y.
$ sapi/cli/php -r 'function foo(){(function($x) use ($y){$y=3; return
$y+$x;})(5);return $y;} var_dump(foo());'
PHP Notice: Undefined variable: y in Command line code on line 1
PHP Notice: Undefined variable: y in Command line code on line 1
NULL
Thanks. Dmitry.
>
> Bob
