Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77947
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.75 as permitted sender)
Message-ID: <543CBD6A.3030701@sugarcrm.com>
Date: Mon, 13 Oct 2014 23:06:34 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Nikita Popov <nikita.ppv@gmail.com>, 
 PHP internals <internals@lists.php.net>
References: <CAF+90c-B74M82xOkT1VguqShE3b2W2YLJ1HX_XzCJtG_WUSxxg@mail.gmail.com>
In-Reply-To: <CAF+90c-B74M82xOkT1VguqShE3b2W2YLJ1HX_XzCJtG_WUSxxg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

I would say we should choose according to the following criteria:

1. Is anybody likely to use it, and if so, will dropping it impede
adoption significantly?
2. Would using it get you into some trouble you can't see easily?
3. How easy it's to detect that something is broken due to BC change?

According to this, I think it would be really good to do this:

- move mysql and ereg out to PECL (disros can bundle them anyway, and
pecl is available for all self builders so adoption won't be hurt much).
- drop incompatible $this context calls (probably seriously messed up code)
- drop magic quotes stuff (if the code relies on magic quotes, something
is seriously wrong). However, I'd consider keeping the get function
(always false) to keep code that checks for it running. It wouldn't
really hurt anybody I think.
- drop dl on FPM - this can lead to some bad crashes
- drop preg_replace() eval - it's a security problem waiting to happen
-

I think it can be problematic for:

- # style comments in ini files, it's harder to detect and fix and as
far as I can see, # doesn't hurt anybody


For the rest, don't really have a strong opinion but agree with Zeev on
each function being removed gets upgrade barrier a little higher and
adds more people to the list of "can not upgrade, need code working".

With ini settings, it's a bit easier since one ini edit fixes everything
on the server, no need to check millions of lines of code. However, if
we just drop them it would be hard to detect that these no longer work,
maybe we should produce an error if those are used?

Same for removing options from stream context - in general, if the
option stopped working, I think it's better to let the user know.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/