Re: Proposal to deprecate create_function()

On Thu, Oct 17, 2013 at 10:48 AM, Rowan Collins <rowan.collins@gmail.com> wrote: > On 17/10/2013 16:47, Pierre Joye wrote: >> >> On Thu, Oct 17, 2013 at 8:31 AM, Rowan Collins <rowan.collins@gmail.com> >> 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? I do. create_function is used for many very valid use cases, safely, much more than /e ever was (and its security impact was much bigger). Deprecating it does not help us nor our users at this stage. Cheers, -- Pierre @pierrejoye | http://www.libgd.org