Good morning!
On 4 Aug 2014, at 06:48, Nikita Nefedov <inefe...@gmail.com> wrote:
> Hey Andrea,
>
> I really love function referencing RFC, this is something I miss in PHP and
> would I have a voting right I'd would +1 even in this state of it.
> But I dislike a bit the fact that we start to use Closure for everything, I
> really wish we had a dedicated type for functions (read functions as a
> first-class citizens).
I was originally going to go to the effort of adding a function reference
class, but then I realised it’d be simpler and make more sense to just use
Closure.
To be honest I don’t think it matters much. If it really bothers enough people,
we could change the class’s name to Function or something and make Closure an
alias, but I don’t see the point.
On 4 Aug 2014, at 07:45, Stas Malyshev <smalys...@sugarcrm.com> wrote:
> This syntax collides with by-ref assignment and by-ref arrays, which is
> not good. Different things should not look the same.
It doesn’t collide, there is no syntactical ambiguity at an engine level, at
least. It does unfortunately look similar, however. The choice of syntax is
largely for a lack of better alternatives. It also matches what C and C++ do. I
had wanted to do something like ‘function foobar’, but that’s clunky and
actually couldn’t be done in the parser. I wondered what Hack does here (since
it needs such a syntax to avoid breaking the type checker), but they have a
horrible fun(‘foobar’) pseudo-function. Someone, I think it was Anthony,
pointed out to me that & wasn’t actually syntactically ambiguous like I’d
thought, so I decided to go with that. Since you can’t reference constants, and
since this doesn’t support dynamic references, I think it will not be that
confusing.
> I'm not sure also how exactly non-closures can function as closures - if
> you take SplFixedArray::getSize and rebind it to SplFileObject, what is
> supposed to happen?
A fatal error, as methods of internal classes can’t be bound to other classes.
This is our current behaviour anyway if you try to do that.
> I also do not understand why one needs &strlen if "strlen" works just
> fine.
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 callable is being
passed. I suppose it also means you could type hint for Closure instead of
callable to guarantee you get an object you can use the Closure methods on.
> Only to declare "PHP now has first-class functions"? You can
> declare it right now. No need to change the syntax for that, since the
> engine does exactly the same and no additional capabilities appear
> (though additional problems - e.g. rebinding non-closures - do).
PHP’s functions aren’t first-class, we just have a way to reference them with
strings. What we do is similar to what C does with function pointers. An
advantage of being able to get normal functions and methods as closures is it
means that anything we add to the Closure class can be used on them. For
example, if we added built-in partial application (something I’d sure like to
see, it’s just difficult to implement), you’d be able to use it on any existing
userland or extension function. If we added built-in currying, a related
feature, you’d also be able to use it. The syntax means PHP no longer has two
classes of functions, essentially.
On 4 Aug 2014, at 12:36, Marco Pivetta <ocram...@gmail.com> wrote:
> Is the advantage of `Closure#call()` only performance? Because I don't see
> other advantages otherwise, and I don't think the performance impact is
> relevant.
There is a performance advantage which I’m going to test at some point, but
that’s not why I propose adding it. It is to simplify binding closures. It’s
not an uncommon operation to want to bind at call-time in other languages, and
it can be useful.
> As for the function referencing RFC, I like it, but it is an annoying syntax
> that seems to have been built just to accomodate the parser, and that can be
> worked around in userland with overhead and more typing:
>
> $functionReference = function ($param) { return functionName($param); };
That doesn’t work properly for class methods, both instance and static. It
doesn’t even work properly for normal functions, as you’re stripping away
parameter information.
> A syntax that I'd like, and which is IMO BC compatible would be`::function`:
>
> array_map(count::function, [[1, 2], [3, 4]]);
>
> This is also very similar and similarly readable to what we have right now
> with PHP 5.5 through the `::class` meta-constant.
> There's also no way to use `function` as a constant anywhere, so it should be
> safe to use that right now.
That syntax isn’t doable in the parser and isn't backwards-compatible anyway.
Classes and functions share the same namespace, so what do you do when I have a
class called FooBar and a function called FooBar? How about if I have a class
with a constant named function? How do you propose to implement this
pseudo-class system where functions act like classes in only one case, when
fetching this fake class constant? How do you deal with the fact that constants
cannot (with very good reason) be objects? The idea is good, it just falls down
from a practical standpoint.
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
