On 4 August 2014 14:11, Andrea Faulds <a...@ajf.me> wrote:
> 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.
The fact that I'm arguing about is "yet another method to maintain" for an
API that can simply live in userland (and is easier to
maintain/upgrade/etc)...
Unless there's a huge overhead, I don't see a problem with creating new
closures: I do a lot of performance-sensitive stuff with `Closure::bind()`
and I don't see how this API could help me.
> > 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.
>
Why do you actually need parameter information here?
Starting from PHP 5.6, dynamic parameters can be passed on via variadics
anyway. By-ref and by-val is also no big deal as well.
This kind of call can be recognized by static analyzers, and can be
refactored by IDEs.
> > 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?
FooBar::methodName::function vs FooBar::function - clear and simple IMO.
Consider http://3v4l.org/SY6vD, http://3v4l.org/YuMZ2 and
http://3v4l.org/9ZRFN
> How about if I have a class with a constant named function?
Not allowed by the language
> 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?
I'm not: `::function` is not a constant, it would be recognized by the
parser directly.
> How do you deal with the fact that constants cannot (with very good
> reason) be objects?
Not sure what you mean with this..
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
