Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69636
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <526002B4.9010808@gmail.com>
References: <525C631E.1050008@gmail.com>
	<1381853515.3980.195.camel@guybrush>
	<526002B4.9010808@gmail.com>
Date: Thu, 17 Oct 2013 08:47:16 -0700
Message-ID: <CAEZPtU7iJwwaY8xVb5a9emwKx0Bie_Xu2F_2AuYU-ijtGiGfZA@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Proposal to deprecate create_function()
From: pierre.php@gmail.com (Pierre Joye)

On Thu, Oct 17, 2013 at 8:31 AM, Rowan Collins <rowan.collins@gmail.com> wr=
ote:
> On 15/10/2013 17:11, Johannes Schl=C3=BCter wrote:
>>
>> In general: Getting rid of it is good. But mind that closures are no
>> full replacement as with create_function() the code can be created on
>> the fly.
>
>
> Yes, I agree that there is no trvial solution which is 100% feature (and
> bug) compatible with create_function(). However, I think the more importa=
nt
> question is whether there are any particular *use cases* which can't be
> easily migrated to a different mechanism.

That's the actual question, why should they?


> My gut feel is that at least 95% of uses of create_function are to create
> dynamic callbacks for usort, preg_replace_callback, array_filter, etc. Fo=
r
> these uses, the implementation as an eval() is a liability, and
> reimplementing with real closures is trivial (assuming no need to run on
> <=3D5.2).

Yes, as many other new features allow cleaner codes. However I do not
see this case as good enough to add more deprecated notices to
perfectly valid codes.

Cheers,
--=20
Pierre

@pierrejoye | http://www.libgd.org