Re: Proposal to deprecate create_function()

From: Date: Thu, 17 Oct 2013 19:23:15 +0000
Subject: Re: Proposal to deprecate create_function()
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-69655@lists.php.net to get a copy of this message
Am 17.10.2013 17:47, schrieb Pierre Joye: > On Thu, Oct 17, 2013 at 8:31 AM, Rowan Collins <rowan.collins@gmail.com> wrote: >> On 15/10/2013 17:11, Johannes Schlüter 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 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. Please note that there are open bugs with "create_function" the should than be fixed including memory issue. > > Cheers, >

« previous php.internals (#69655) next »