Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76343
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.207 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <53DFD1E3.9010206@sugarcrm.com>
Date: Mon, 4 Aug 2014 20:10:45 +0100
Cc: Marco Pivetta <ocramius@gmail.com>,
 Nikita Nefedov <inefedor@gmail.com>,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <71CF93C4-2D90-44B1-9314-E27487E326FF@ajf.me>
References: <D17EB1B8-7A7E-419B-AF55-0ADCAB4CFEB3@ajf.me> <53DF2BED.10103@sugarcrm.com> <06F3EF08-21B1-49AD-9D9D-5043C69AC1D8@ajf.me> <53DFD1E3.9010206@sugarcrm.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Subject: Re: [PHP-DEV] [RFC] Closure::call and Function Referencing as Closures
From: ajf@ajf.me (Andrea Faulds)


On 4 Aug 2014, at 19:33, Stas Malyshev <smalyshev@sugarcrm.com> wrote:

>> It doesn=92t collide, there is no syntactical ambiguity at an engine
>> level, at least. It does unfortunately look similar, however. The
>=20
> That's the collision. It looks exactly the same, but does entirely
> different thing. This is not good.

It doesn=92t look exactly the same, you can=92t reference a constant.

> It doesn't match what C and C++ do - it does a completely different
> thing from what C and C++ do. It's not an address and it's not a =
reference.

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.

>> The hope is that it=92d be more obvious a function is being =
referenced
>> without needing to know the signature of the function to which the
>=20
> I don't understand how for writing "strlen" you need to know its =
signature.
>=20
>> callable is being passed.

I said "the signature of the function to which the callable is being =
passed=94. If I do this:

    foo(=93foobar=94);

I don=92t know if foo takes a callable or it takes a string. It=92s not =
clear, without knowing foo=92s signature, what we=92re trying to give =
it. However, this is clearer:

    foo(&foobar);

In this case, if we know of the & syntax, it is clear a function is =
being passed.

> So now
> callable is not enough and we need also typing by Closure? But wait,
> callable is still supported for calling, so what you want to do with
> Closure? Right now it has two methods - for binding - and both are not
> guaranteed to work at all - as you just said, it would fail to work on
> any internal function and on most non-internal functions too, since =
they
> have no idea what to do when bound. So you get an object that actually
> guarantees nothing at all.

Well, people can always write broken code that passes nonsensical =
arguments. Equally at the moment, if someone asks for a comparison =
function, I can pass strlen is I really want to. I don=92t see what your =
point is. Closures have methods that can be used, strings do not. Yes, =
this doesn=92t work for some closures. I can pass invalid arguments to =
other methods too.

> In what meaning they are not first-class that your change is making =
them
> first-class?

Actually, arguably, PHP=92s functions currently are first-class as they =
full fill the three main requirements if you use strings (or arrays for =
methods). They can be passed as arguments, returned, and assigned to =
variables, or at least strings and arrays can be. My apologies.

> But it can not. E.g. you can not bind such things. They can not have
> environments. They only thing you can do with them is call them - but
> you can do it right now!

You *can* actually bind a user function, it=92s just not useful for most =
user functions which don=92t make use of $this. Although if you really =
want to, you can write one which does. You could already do this, and it =
would work perfectly.

> You can do partial application to any callable just now by generating =
an
> anon function that applies it via call_use_function. The only thing
> introducing Closure there would change is how the method being called =
is
> named.

Right, but you could add an internal method to do partial application =
for you.

> We don't have two classes of functions right now. If you go to engine
> level, we have more than that, if you stay on PHP level, you just have
> callable, which is not really a function but rather a way to address a
> function.

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.

--
Andrea Faulds
http://ajf.me/