Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76348
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.75 as permitted sender)
Message-ID: <53DFE91D.2040300@sugarcrm.com>
Date: Mon, 04 Aug 2014 13:12:13 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Andrea Faulds <ajf@ajf.me>, Rowan Collins <rowan.collins@gmail.com>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <D17EB1B8-7A7E-419B-AF55-0ADCAB4CFEB3@ajf.me> <53DF2BED.10103@sugarcrm.com> <06F3EF08-21B1-49AD-9D9D-5043C69AC1D8@ajf.me> <53DFE1FC.5040206@gmail.com> <BDDFD20F-1885-4106-BA7E-2A837C02ADF9@ajf.me>
In-Reply-To: <BDDFD20F-1885-4106-BA7E-2A837C02ADF9@ajf.me>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Closure::call and Function Referencing as Closures
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> Right, while &FooBar::$methodname would conflict, &$classname::foo
> would not. I do neither for the sake of consistency, as having one
> but not the other worse might cause confusion. This has the benefit,
> I suppose, that & is completely static. You can see at “compile-time”
> whether it’s valid and what function is being used. I think that

Except that it's not "compile-time" - you can't create Closure in
compile time. Moreover, this precludes a natural extension of this
functionality. So let's assume for a very brief moment that we had some
function doit(Closure $foo) which does something very useful with
closures but can not accommodate callables. So we do something like that:

$func = &Foo::getBar;
doit($func);

Now after some time we come back and want to refactor this code, and
allow it to work not only on Foo::getBar, but also on Foo::getBaz,
Foo::getQux and so on. PHP is dynamic and awesome, so we just do this:

$methodname = 'get'.$what;
// we are smart and won't allow to trick us into calling something that
does not exist!
if(!is_callable(['Foo', $methodname])) {
  throw new Exception("Bad method $methodname");
}
$func = &...

Oops! We can't write it anymore as $func = &$methodname means something
entirely different! Why this refactoring, very natural for PHP and
looking like everything everybody was doing for years, failed? Because
we were trying to reuse syntax that belonged to somebody else. It's like
taking somebody else's car for a joyride - you can say that guy wasn't
really using it right now, but it's not your car, so you get in trouble
very soon.

Now, could somebody explain me, why the syntax of generating closures
from functions is so useful we really need a language construct for it,
but only if the function name is static and known in advance, and
becomes useless once we try to generate function name dynamically
(something PHP code does all the time and something from which PHP
derives a lot of its flexibility)?

I personally doubt we need any syntax at all to convert callables to
closures, since most of the things you do with closures should support
callables anyway, except some very narrow corner cases. But assuming we
find such case, the syntax or function doing it should work on all
callable forms, otherwise trying to use it in a real project would hit a
wall very fast.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/