Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91284
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 212.232.28.123 cause and error)
Reply-To: internals@lists.php.net
References: <CAF+90c_1zO91x-4Madqm3F8gkKDT7jZKVZSbBuYMbnDCADrv_A@mail.gmail.com>
 <24.F3.62769.A4226C65@pb1.pair.com>
To: internals@lists.php.net
Message-ID: <56C62A13.50701@fleshgrinder.com>
Date: Thu, 18 Feb 2016 21:31:15 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <24.F3.62769.A4226C65@pb1.pair.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1
From: php@fleshgrinder.com (Fleshgrinder)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2/18/2016 8:57 PM, Andrea Faulds wrote:
> 
> Nikita Popov wrote:
>> https://wiki.php.net/rfc/deprecations_php_7_1
> 
> 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.
> 
> 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!
> 

+1 for all that are in the RFC and I would like to second Andrea’s
proposals. All of them including utf8_encode() and utf8_decode().
Those two are used incorrectly in most cases I encounter them. People
seem to assume that they are able to encode anything to proper UTF-8
when calling utf8_encode().

There are more questionable string functions available:

- - quotemeta() -- bad function name and purpose is unclear.
- - convert_cyr_string() -- iconv() again ...

Candidates for moving to appropriate section of ext/ (or PECL) since
they are all kind of special and nothing a *normal* program would ever
need. Especially since they target English only and there are much
better algorithms and tools available to work with such use cases.

- - levenshtein()
- - metaphone()
- - similar_text()
- - soundex()

- -- 
Richard "Fleshgrinder" Fussenegger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWxioTAAoJEOKkKcqFPVVrE8oQAL4GmeeBFGTBiE90sYutyljz
hkAZEKBkFVnSK1Ta92DB4+3mWYYtce7C6th9QsqXP871+XAQ92E69YTjP0GrcAm+
Q62kHWzhtDwsN1cePz3DVfuiuNZ0d2mGWoW4ak1azMhWbQGjx+c7nEiugmWOzsRO
WjSJrd2SoZClSy/yGhmqs/5OFdj3hlnI4KX0xsM4A03I+reKqZc3VOWyZFXOqjBK
VK+Bj8G8hz5bNYk3WFXr2NNA8/r4FAOdOZS4CSsfHTbux/8szqbz2dB2V7oUU9FV
8Z5tpPNPe37GyLjcxvlqcM8QGVjwc3zbxoFK2Jfz6UlnRQxDqH/6XRqNMQF1JslS
7FS8jc57SaUb/9tcg+XwOOkH6yoc30JXjq1BBR0SuNGCB1HDG4vcvWIus2YcI0xO
hhPmp/8Rqujv0ybhuikPBdM1XK5E/3dk+G9xsE2sXNWRYbaeu1moahm52RUWnoFx
YNAHeYIsA3M1LSncFwiTop6ouqmAAN55wo1rGfocilrwo4lPBF0F6TP8LEeT55vb
AwS70sp/gVfyoTN3MEzubn5XZ3jKft82ZEWIdEBwGs7L3BctE2ubCDozrOBqes9W
sVcj2zhQV636BC8UbKx0x+5PzlGFDX7xayWvP1J8aks+Th35G7WkU4gb5ajLLXOa
W2sMr3dl5EzfgKVLI6+n
=Ip+5
-----END PGP SIGNATURE-----