Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76335
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.200 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <CADyq6s+2amf_K53cGN5pn8XC8ZPc3jLwVnywoiJaVm0fK3YHRg@mail.gmail.com>
Date: Mon, 4 Aug 2014 14:02:58 +0100
Cc: Stas Malyshev <smalyshev@sugarcrm.com>,
 Nikita Nefedov <inefedor@gmail.com>,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <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>
To: Marco Pivetta <ocramius@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Closure::call and Function Referencing as Closures
From: ajf@ajf.me (Andrea Faulds)


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=92t* we allow binding $this at runtime like 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=92t cause any problems, I don=92t see why we =
shouldn't.

If it=92s really such a maintainability problem (I wouldn=92t say so, =
the function=92s quite simple), then you can get me to maintain it. =
After all, I wrote it.

> 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.
>=20
> This kind of call can be recognized by static analyzers, and can be =
refactored by IDEs.

It still has the problem of not allowing re-scoping or arbitrary $this =
binding. Your solution works only for global functions. It also removes =
the benefit of knowing at the point of reference whether the function =
actually exists.

> FooBar::methodName::function vs FooBar::function - clear and simple =
IMO.

It might be clear and simple, but I don=92t think it=92s realistic. I=92m =
not sure if it=92s even possible in the parser, as you=92d be fetching a =
class then suddenly backtracking and deciding you actually want to do =
something else entirely. Of course, with Nikita=92s AST, this probably =
is possible.

> How about if I have a class with a constant named function?
>=20
> Not allowed by the language

Good point.
=20
> 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?
>=20
> 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=92t do that, to =
the best of my knowledge. I think using ::function over-complicates =
things.

That said, it is another option, just not one we could implement =
immediately or that I personally am particularly fond of.
--
Andrea Faulds
http://ajf.me/