Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76334
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <06F3EF08-21B1-49AD-9D9D-5043C69AC1D8@ajf.me>
References: <D17EB1B8-7A7E-419B-AF55-0ADCAB4CFEB3@ajf.me> <53DF2BED.10103@sugarcrm.com>
 <06F3EF08-21B1-49AD-9D9D-5043C69AC1D8@ajf.me>
Date: Mon, 4 Aug 2014 14:27:57 +0200
Message-ID: <CADyq6s+2amf_K53cGN5pn8XC8ZPc3jLwVnywoiJaVm0fK3YHRg@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, Nikita Nefedov <inefedor@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113a48dea3223504ffccdf09
Subject: Re: [PHP-DEV] [RFC] Closure::call and Function Referencing as Closures
From: ocramius@gmail.com (Marco Pivetta)

--001a113a48dea3223504ffccdf09
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 4 August 2014 14:11, Andrea Faulds <ajf@ajf.me> wrote:

> On 4 Aug 2014, at 12:36, Marco Pivetta <ocramius@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=E2=80=99m going to test at some =
point,
> but that=E2=80=99s not why I propose adding it. It is to simplify binding=
 closures.
> It=E2=80=99s not an uncommon operation to want to bind at call-time in ot=
her
> 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 =3D function ($param) { return functionName($param);=
 };
>
> That doesn=E2=80=99t work properly for class methods, both instance and s=
tatic. It
> doesn=E2=80=99t even work properly for normal functions, as you=E2=80=99r=
e 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=E2=80=99t doable in the parser and isn't backwards-compat=
ible
> 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/

--001a113a48dea3223504ffccdf09--