On Thu, Oct 17, 2013 at 10:48 AM, Rowan Collins <[email protected]> wrote:
> 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?
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