Re: Proposal to deprecate create_function()
| From: | Marc Bennewitz | 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,
>