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
