Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76336
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <9ED40E65-ECFA-40F3-BB61-24D38D4C3E8E@ajf.me>
References: <D17EB1B8-7A7E-419B-AF55-0ADCAB4CFEB3@ajf.me> <53DF2BED.10103@sugarcrm.com>
 <06F3EF08-21B1-49AD-9D9D-5043C69AC1D8@ajf.me> <CADyq6s+2amf_K53cGN5pn8XC8ZPc3jLwVnywoiJaVm0fK3YHRg@mail.gmail.com>
 <9ED40E65-ECFA-40F3-BB61-24D38D4C3E8E@ajf.me>
Date: Mon, 4 Aug 2014 15:14:57 +0200
Message-ID: <CADyq6sLA2TGbg7q_5K-CX_i-JcwHsAKTsp4GsXtFBqC=RHn0hA@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=001a11c292f0c3f44d04ffcd87ae
Subject: Re: [PHP-DEV] [RFC] Closure::call and Function Referencing as Closures
From: ocramius@gmail.com (Marco Pivetta)

--001a11c292f0c3f44d04ffcd87ae
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 4 August 2014 15:02, Andrea Faulds <ajf@ajf.me> wrote:

>
> On 4 Aug 2014, at 13:27, Marco Pivetta <ocramius@gmail.com> wrote:
>
> > 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.
>
> Well, perhaps this API is not aimed at you specifically. The broader
> question is why *shouldn=E2=80=99t* we allow binding $this at runtime lik=
e we do
> for any other parameter? Creating a closure only to immediately throw it
> away is a waste of code and time. Since we can permit this, it is useful,
> and it doesn=E2=80=99t cause any problems, I don=E2=80=99t see why we sho=
uldn't.
>

It is a waste of memory, but I'd first like to see an actual real-world
use-case for it. There are simpler ways to avoid the memory usage, by
allowing stuff like following:

$something =3D function () use (& $object) {};

Then binding the closure to a specific scope and forgetting about `$this`.
That is efficient both memory and cpu-wise.

If it=E2=80=99s really such a maintainability problem (I wouldn=E2=80=99t s=
ay so, the
> function=E2=80=99s quite simple), then you can get me to maintain it. Aft=
er all, I
> wrote it.
>

Yes, but upgrading PHP is a mess (from a
business/bureaucracy/devops/whoeverhatesmeatwork perspective. You can ask
that to some other users of this mailing list that solely use the ml to
vent about that.
Upgrading libraries is easy.

> FooBar::methodName::function vs FooBar::function - clear and simple IMO.
>
> It might be clear and simple, but I don=E2=80=99t think it=E2=80=99s real=
istic.


PHP 5.5 introduced the `::class` construct, which I currently use quite a
lot and makes refactoring a breeze. I don't see why this syntax wouldn't
work.


> > How do you propose to implement this pseudo-class system where function=
s
> 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.
>
> Right, but at least under the current parser, you couldn=E2=80=99t do tha=
t, to the
> best of my knowledge. I think using ::function over-complicates things.
>

No clue how complicated `Foo::bar::function` gets with the current parser,
but if that's the problem, then I'd ask Nikic directly, as he may find an
easy solution if the AST-based parsing makes it into core.

That said, it is another option, just not one we could implement
> immediately or that I personally am particularly fond of.
>

My point here is consistency. I'd love to have the same kind of static
reference for classes and functions/methods. Even `::const` eventually, as
well as other symbols if anyone can think of them.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--001a11c292f0c3f44d04ffcd87ae--