I know a straw man argument when I see one (:

/e suggests that eval is a casual thing to be sprinkled into typical
search and replace operations. It also suggests that putting PHP code
in a quoted string is probably the easy way to solve your problem.
It's often discovered before the developer has even heard of
preg_replace_callback.

eval() does not have these PR problems (:

It's there for those who are truly looking for it.

On Sun, Feb 5, 2012 at 11:21 AM, Pierre Joye <pierre....@gmail.com> wrote:
> hi,
>
> I think we should remove eval at the same time then. As the risk is
> exactly the same in both situations. Eval is just as evil and can be
> avoided as well (or any other similar features, not sure if other exts
> allow that).
>
> Cheers,
>
> On Sun, Feb 5, 2012 at 3:59 PM, Nikita Popov <nikita....@googlemail.com> 
> wrote:
>> Hi internals!
>>
>> I have written an RFC that proposes to *deprecate* and *remove* the /e 
>> modifier:
>>
>> https://wiki.php.net/rfc/remove_preg_replace_eval_modifier
>>
>> Comments welcome!
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>
>
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



-- 
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to