Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:57726 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 9414 invoked from network); 5 Feb 2012 16:29:05 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Feb 2012 16:29:05 -0000 Authentication-Results: pb1.pair.com smtp.mail=tom@punkave.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=tom@punkave.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain punkave.com designates 209.85.210.170 as permitted sender) X-PHP-List-Original-Sender: tom@punkave.com X-Host-Fingerprint: 209.85.210.170 mail-iy0-f170.google.com Received: from [209.85.210.170] ([209.85.210.170:32800] helo=mail-iy0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E6/00-09047-05EAE2F4 for ; Sun, 05 Feb 2012 11:29:04 -0500 Received: by iakk32 with SMTP id k32so8326547iak.29 for ; Sun, 05 Feb 2012 08:29:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.189.137 with SMTP id gi9mr17173807igc.29.1328459340837; Sun, 05 Feb 2012 08:29:00 -0800 (PST) Received: by 10.231.178.65 with HTTP; Sun, 5 Feb 2012 08:29:00 -0800 (PST) In-Reply-To: References: Date: Sun, 5 Feb 2012 11:29:00 -0500 Message-ID: To: Pierre Joye Cc: Nikita Popov , PHP internals Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PHP-DEV] [RFC] Deprecate and remove /e modifier from preg_replace From: tom@punkave.com (Tom Boutell) 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 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 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