Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57731
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.170 as permitted sender)
References: <CAF+90c9qoyzBf+FpBxMdX0FByy5xB+7x3xi3kNxdvWX=_uz=mg@mail.gmail.com> <CAEZPtU7mYOB6RTHPFb8B76bPsZiFki6J5sJCMViGD7vK8Fdiyg@mail.gmail.com> <4F2EAF7D.9080506@thelounge.net> <CAORXhGKBPehGLvZsj9D4Oi2Fo4FnV+esyg_QNkuv3cO7uFn6qw@mail.gmail.com>
In-Reply-To: <CAORXhGKBPehGLvZsj9D4Oi2Fo4FnV+esyg_QNkuv3cO7uFn6qw@mail.gmail.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii
Message-ID: <60BDBA28-4E97-4C60-8E31-E34F7E4831AC@gmail.com>
Cc: Reindl Harald <h.reindl@thelounge.net>,
 "internals@lists.php.net" <internals@lists.php.net>
Date: Sun, 5 Feb 2012 10:45:13 -0600
To: Tom Boutell <tom@punkave.com>
Subject: Re: [PHP-DEV] [RFC] Deprecate and remove /e modifier from preg_replace
From: mikegstowe@gmail.com (Michael Stowe)

Perhaps rather than killing it we should just emphasize it more in the docum=
entation (ie on preg_replace and not only in pattern modifiers).=20

But I have found the /e modifier to be very useful in the past. Unfortunatel=
y, just having woken up I can't remember exactly where and how I used it, lo=
l.=20

Perhaps another option, if it's a security concern is the ability to turn of=
f the /e modifier, and have it off by default. This way we can protect our l=
ess experienced programmers, while keeping it available for more advanced us=
e cases.=20

Just my two cents + inflation

- Mike

Sent from my iPhone

On Feb 5, 2012, at 10:37 AM, Tom Boutell <tom@punkave.com> wrote:

> A sense of humor is important when reading mailing lists frequented by
> extremely clever people (:
>=20
> On Sun, Feb 5, 2012 at 11:34 AM, Reindl Harald <h.reindl@thelounge.net> wr=
ote:
>> what he hell - if you kill eval you would kill the whole
>> work of my life and yes i know that eval is evil and
>> it is only used at one place which is a central and
>> real important to include modules and set parameters
>> dynamically
>>=20
>> the /e modifier is a total other dimension because it can
>> be used by people not knowing what they are doing exactly
>> by C&P any code snippet
>>=20
>> eval() is a documentated function
>>=20
>> Am 05.02.2012 17:21, schrieb Pierre Joye:
>>> 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).
>>>=20
>>> Cheers,
>>>=20
>>> On Sun, Feb 5, 2012 at 3:59 PM, Nikita Popov <nikita.ppv@googlemail.com>=
 wrote:
>>>> Hi internals!
>>>>=20
>>>> I have written an RFC that proposes to *deprecate* and *remove* the /e m=
odifier:
>>>>=20
>>>> https://wiki.php.net/rfc/remove_preg_replace_eval_modifier
>>>>=20
>>>> Comments welcome!
>>=20
>=20
>=20
>=20
> --=20
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com
> window.punkave.com
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20