Re: Proposal to deprecate create_function()

From: Date: Thu, 17 Oct 2013 21:22:20 +0000
Subject: Re: Proposal to deprecate create_function()
References: 1 2 3 4 5 6 7 8  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message 
On 17/10/2013 20:29, Pierre Joye wrote:

On Thu, Oct 17, 2013 at 11:24 AM, Rowan Collins <[email protected]> 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.

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:

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.

Q: Can code be migrated to the new solution in advance?
A: Yes, for all supported versions of PHP...

Q: ...OK, but what about code bases which still run on older releases?
A: Private code bases will generally either run entirely on an old release (in which case BC isn't an issue) or upgraded entirely to a new release (in which case BC is a matter of upgrade cost). Public code, however, is often written to support a wide range of releases, to maximise the install base. An obvious example is Wordpress, which currently has a minimum version requirement of 5.2.4, and supported PHP 4 until remarkably recently.

If create_function were removed in version X (which is not right now), there would be an issue if a project such as Wordpress decided to support both 5.2 *and* version X from the same code base. The code base could then contain neither create_function nor anonymous functions - unless some wrapper(s) were written which abstracted both, which is possible for all but the most exotic usages.

For some value of X, it is reasonable to assume that this will not be the case, although when depends a lot on external factors. I don't know whether "X is too far in the future" should be considered an argument against deprecating or not. On the one hand, a long period of deprecation is a good thing, as it gives people time to plan a strategy for the eventual removal; on the other, it makes it uncertain whether you should pay attention to the deprecation yet or not.

Q: How much legacy code is "out there" that uses the feature?
A: This is probably the biggest issue, and the number one reason for not removing it would be the inconvenience of editing old code in order to run it on newer systems. Again, we are trying to predict future trends here: at the time of version X, how much old code will be around for which removing create_function would be a significant part of the upgrade cost?

I'm not proposing to know the "right" answer here, but I'd be interested to hear something other than a gut reaction of exactly why deprecating it would be a bad idea (or an insufficiently good one).

Apologies again for long-windedness.
Regards,

-- 
Rowan Collins
[IMSoP]

Thread (33 messages)

« previous php.internals (#69658) next »