Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88669
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <561182F5.2030508@gmail.com>
References: <CA+kxMuSFP=vooMzCYMapTsis6RGBVd-T4YM9z3YuxgF3Rcj6EQ@mail.gmail.com>
	<8D.64.31315.E67F0165@pb1.pair.com>
	<561182F5.2030508@gmail.com>
Date: Sun, 4 Oct 2015 23:07:32 +0200
Message-ID: <CALJZF3iP_hp9r2r+vaYR4rPd5F3o+i2rLz7+KNKNpr94B-Herw@mail.gmail.com>
To: Stas Malyshev <smalyshev@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b41447808ee1d05214dc9fe
Subject: Re: [PHP-DEV] Re: [RFC] [DISCUSSION]: Closure from callable
From: mike.php.net@gmail.com (Michael Wallner)

--047d7b41447808ee1d05214dc9fe
Content-Type: text/plain; charset=UTF-8

On 4 Oct 2015 21:50, "Stanislav Malyshev" <smalyshev@gmail.com> wrote:
>
> Hi!
>
> > I don't like that it's a function. Closure is a class, classes can have
> > static and instance methods, and closure() looks like something that
> > should be a method on Closure. In fact, it creates a closure, which a
> > constructor would usually do. If we want to make it avoid duplication,
> > okay, then it could be a static method. But I'm unconvinced it should be
> > a function. Constructors go in their classes, we don't leave them lying
> > around as global functions. That's messy and inconsistent.
>
> Agree. Closure::fromCallable sounds like a good option.
> That being said, I'm not sure how much need is for this - i.e. you can
> always make a closure by just doing function() { return $this->blah(); }
> if you need it. But the bigger question would be why you need more
> specific type (Closure) instead of more generic (callable) and aren't
> you overspecifying in that case?
>
> And if we're into performance optimization - which should almost never
> be done on language construct level, because performance considerations
> vary and language constructs are forever - then it would be much better
> to look into tail call optimizations. That would solve the barrier
> between [$this, "foo"] and function() { return $this->foo(); } in many
> practical cases.
>

I think the origin of this intention is, that calling a callable just by
`$callable()` does not work consistently -- see the othe RFC by Dan -- and
that call_user_func() suffers from a (mythical?) performance issue.

--047d7b41447808ee1d05214dc9fe--