Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69663
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5260550C.1040406@gmail.com>
References: <525C631E.1050008@gmail.com>
	<1381853515.3980.195.camel@guybrush>
	<526002B4.9010808@gmail.com>
	<CAEZPtU7iJwwaY8xVb5a9emwKx0Bie_Xu2F_2AuYU-ijtGiGfZA@mail.gmail.com>
	<526022E1.1040406@gmail.com>
	<CAEZPtU53CH-gGZK7kJnYrPu=VAc0-M-4DUryDBH7TgcEJ=Y6QA@mail.gmail.com>
	<52602B7A.3080509@gmail.com>
	<CAEZPtU7_0oY1Ya=df20-R3Fhz1XFfoUC3vrY7i4yJi+ZU8_oyw@mail.gmail.com>
	<5260550C.1040406@gmail.com>
Date: Thu, 17 Oct 2013 22:25:16 -0700
Message-ID: <CAEZPtU5baF5uSbBnRHJ-RTNgnVZ6rukG-ynD5fpq9Q69Aop-qQ@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Proposal to deprecate create_function()
From: pierre.php@gmail.com (Pierre Joye)

On Thu, Oct 17, 2013 at 2:22 PM, Rowan Collins <rowan.collins@gmail.com> wrote:
> On 17/10/2013 20:29, Pierre Joye wrote:
>>
>> On Thu, Oct 17, 2013 at 11:24 AM, Rowan Collins <rowan.collins@gmail.com>
>> wrote:
>>>
>>> If create_function did not exist, would any of those use cases persuade
>>> you that it should?
>>
>> Not with latest PHP releases, but that's the point: we try to keep BC.
>
>
> Well, to an extent - it is not true that any PHP script which works in PHP
> 5.2 will work in PHP 5.5, let alone work identically. For instance,
> call-time pass-by-reference causes a fatal error in PHP >= 5.4; unlike calls
> to create_function, it's tricky to search for code that used that, and to be
> confident of the implications of changing it.

Comparing a widely used feature, working well with something that
never really worked (and why we have removed it) is hardly a good
argument to remove create_function :-)

> So it is not a case of "thou shalt not break BC", but a case of "how big a
> BC break is this?" Obviously, there are other questions (e.g. challenging
> the reasons *for* removing it), but I'd like to break this one apart a bit:


It is, create_function works and is widely used. We can provide
good/better documentation to inform our users about better, cleaner,
sexier ways to achieve the same but deprecating it in a 5.x release is
not going to work out well.


> Q: Is it difficult to upgrade code to not use the feature?
> A: For 95%+ of cases, my contention is that refactoring use of
> create_function() to use closures is pretty trivial. A few cases which
> explicitly used its quirks may need a wrapper around eval() etc. Nobody has
> yet piped up with a use case which would rely on the harder-to-emulate
> aspects of the current implementation.

Code should not be updated in the 1st place unless there is a really
critical issue, something we absolutely have to change. That's not the
case here, we do not enforce good practices (or we could enforce so
many other things in the language ;).


Also I think we disagree on that, we discussed pretty much all points,
let face it :). I have to suggest to create a RFC if you feel like it
has to be deprecated and see what other developers want.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org