Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76344
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.91 as permitted sender)
Message-ID: <53DFDE99.5080003@sugarcrm.com>
Date: Mon, 04 Aug 2014 12:27:21 -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>
CC: Marco Pivetta <ocramius@gmail.com>, 
 Nikita Nefedov <inefedor@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <D17EB1B8-7A7E-419B-AF55-0ADCAB4CFEB3@ajf.me> <53DF2BED.10103@sugarcrm.com> <06F3EF08-21B1-49AD-9D9D-5043C69AC1D8@ajf.me> <53DFD1E3.9010206@sugarcrm.com> <71CF93C4-2D90-44B1-9314-E27487E326FF@ajf.me>
In-Reply-To: <71CF93C4-2D90-44B1-9314-E27487E326FF@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!

> It doesn’t look exactly the same, you can’t reference a constant.

That's why it is bad - because it looks like you're referencing a
constant, but in fact it does something completely unrelated.

> In C and C++ you get a function pointer. Here you get a closure. In
> both cases you get something you can call, pass as an argument and
> return.

You can pass and return anything. But it C and C++, & means physical
address of an entity - the place in memory where it is stored. In your
syntax, it means creating a new object that contains some code that if
some method of this object is invoked it would call the function. It's
not even close to being the same - the only similarity is that both can
be passed as argument, which can also be said about literally every
other value in the language.

> I don’t know if foo takes a callable or it takes a string. It’s not
> clear, without knowing foo’s signature, what we’re trying to give it.
> However, this is clearer:
> 
> foo(&foobar);

In real life, it'd be foo($foobar) and your argument would not work
anyway. Function types are never obvious from function call, that's why
people have docs and IDEs. Adding new syntax just to say "this means
callable" is not a good idea, if you really really need it in your code,
just comment it. Or use an IDE which would tell you foo's signature.
This is so narrow case that I can't really see how it can justify new
syntax, even more - one that collides with existing one.

> function, I can pass strlen is I really want to. I don’t see what
> your point is. Closures have methods that can be used, strings do

My point is that this syntax does not add anything we can't do now, is
confusing by colliding with existing syntax, based on Closure while we
in advance know no existing methods of Closure would work on it and
promises to provide "first class functions" where in fact not adding
anything that doesn't exist right now.

> Right, but you could add an internal method to do partial application
> for you.

You could create such method right now, you don't need new syntax for
that. It also would work on any function, not just on special-syntax ones.

> We do have two classes of functions from a userland perspective:
> Closures and functions/methods. The former are passed around as
> objects with methods, the latter are passed around with strings or
> arrays.

The fact that closures have methods is an implementation detail, which
is important only if you want to rebind them. Which is exactly where
your case would produce fatal errors. But if you really want to wrap
everything into Closure, just make a function that does:

function closureify($callable) {
return function(...$args) use($callable) {
call_user_func_array($callable, $args); }
}

It's an one-liner, though its usefulness is doubtful for me.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/