Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97469
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.54 as permitted sender)
To: Nikita Popov <nikita.ppv@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <CAF+90c8Wox0wadAVPsP83er=G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com>
 <CAF+90c8+PKJMzD3GM=VJDi5wCWArZhY0r7=sHv4U-wNXTpn7aA@mail.gmail.com>
Message-ID: <753c3900-0d59-8d0d-3a53-863f42465b49@gmail.com>
Date: Mon, 26 Dec 2016 22:52:31 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0)
 Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <CAF+90c8+PKJMzD3GM=VJDi5wCWArZhY0r7=sHv4U-wNXTpn7aA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.2
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

>>     https://wiki.php.net/rfc/deprecations_php_7_2

Reading through the list, I find several categories:

Completely ok:

(unset) - don't see any sane use case anyway
gmp_random

Can cause breakage but it's ok:

$php_errormsg
__autoload
mbstring.func_overload
parse_str() - people can use it in functions, it doesn't have to be
globals. But it's cleaner with second arg.
$errcontext

Don't see a reason to remove:

(binary) cast and b"" - yes, they are not currently doing anything. But
they don't also hurt anything.

High breakage potential:

each() - I've seen a lot of code using each. Yes, it's not the best way.
A lot of people write code not in absolutely best way but in a way they
like to. Argument about list() proposed in RFC makes little sense to me
- since problem is with list() and not each() why each() should be
deprecated because of it? And I certainly object its removal.

create_function() - yes, there are closures now. But there's a lot of
code created when there were none, and that code works, and there's no
reason to break it. I'd probably be OK with deprecation warning but not
with removal.

Special case:
assert() - if the string arg is a security issue, deprecating it
achieves nothing. So I'm not sure I understand the argument for
deprecation - if string assert is a problem we probably should make
assert() construct instead check if assert is used in eval form, not by
argument count?

-- 
Stas Malyshev
smalyshev@gmail.com