Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:91282 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 83191 invoked from network); 18 Feb 2016 19:58:03 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Feb 2016 19:58:03 -0000 X-Host-Fingerprint: 176.252.240.115 unknown Received: from [176.252.240.115] ([176.252.240.115:12558] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 24/F3-62769-A4226C65 for ; Thu, 18 Feb 2016 14:58:02 -0500 Message-ID: <24.F3.62769.A4226C65@pb1.pair.com> To: internals@lists.php.net References: Date: Thu, 18 Feb 2016 19:57:58 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 176.252.240.115 Subject: Re: [RFC] Deprecations for PHP 7.1 From: ajf@ajf.me (Andrea Faulds) Hi Nikita, Nikita Popov wrote: > I've created a bulk-deprecation RFC for PHP 7.1: > https://wiki.php.net/rfc/deprecations_php_7_1 I'd be fine with getting rid of all of the ones suggested so far (__autoload, $php_errormsg, create_function, rand/srand). I've actually used create_function on occasion for programmatically generating functions (in particular to create a function for each PHP operator), but it's trivially polyfillable, and it'd be better if people were implementing it themselves (and thus knowing it's based on eval()) than using it directly without this knowledge. Regarding rand() and srand(), I'm fine with getting rid of them. Note that we should also deprecate getrandmax() at the same time, though. It's the function which returns the C RAND_MAX constant. > I'm using this RFC to collect various deprecations targeting PHP 7.1, as > having individual RFCs for these is too much management overhead. Each > deprecated feature will get its own vote, of course. > > This RFC is incomplete -- I'm posting it now so people can suggest other > things that should be deprecated. I expect it to grow over time and don't > plan to vote on it in the immediate future. Hmm. Well, if we're doing mass deprecations, maybe we should finally get rid of hebrev() and hebrevc()? It feels out-of-place to have a poorly-documented standard library function specifically for converting between two different legacy 8-bit encodings used for Hebrew, especially when one of them is just the other with nl2br() included! Users who need to convert between different variants of ISO-8859-8 can use iconv() instead, or perhaps use a userland polyfill of hebrev/c(). That said, hebrev/c() might be used a lot in legacy code, and there's probably little harm in keeping it. Similarly, we have utf8_decode() and utf8_encode() for converting between ISO-8859-1 and UTF-8, which could also be replaced with iconv(), but they're probably heavily used. Even if we don't get rid of or deprecate any of those functions, they should probably be moved into a more appropriate section of ext/ and the manual. Thanks! -- Andrea Faulds https://ajf.me/