Re: Proposal to deprecate create_function()

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

On Thu, Oct 17, 2013 at 8:31 AM, Rowan Collins <[email protected]> wrote:

Yes, I agree that there is no trvial solution which is 100% feature (and bug) compatible with create_function(). However, I think the more important 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. For
these uses, the implementation as an eval() is a liability, and
reimplementing with real closures is trivial (assuming no need to run on
<=5.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.


I guess to me it seems much the same as deprecating the /e modifier in preg_replace: code using it right now largely works, but it presents a security risk that many users probably don't appreciate.

I wasn't subscribed when that was being discussed, so if there are points from that discussion which would be pertinent here, I'd welcome links/summaries.

The only real difference I can see with create_function is that it is/was more widely used; is that your concern, or do you see a fundamental difference between the two situations?

-- 
Rowan Collins
[IMSoP]

Thread (33 messages)

« previous php.internals (#69645) next »