On 4 Aug 2014, at 19:33, Stas Malyshev <smalys...@sugarcrm.com> wrote:
>> It doesn’t collide, there is no syntactical ambiguity at an engine
>> level, at least. It does unfortunately look similar, however. The
>
> That's the collision. It looks exactly the same, but does entirely
> different thing. This is not good.
It doesn’t look exactly the same, you can’t 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’d be more obvious a function is being referenced
>> without needing to know the signature of the function to which the
>
> I don't understand how for writing "strlen" you need to know its signature.
>
>> callable is being passed.
I said "the signature of the function to which the callable is being passed”.
If I do this:
foo(“foobar”);
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 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’t see what your point is. Closures have
methods that can be used, strings do not. Yes, this doesn’t 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’s 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’s just not useful for most user
functions which don’t 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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
