Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113648
Message-ID: <44640470-3BC3-4845-BE2B-97CCCA942D41@benramsey.com>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_DFE42DB5-AF53-497E-93CB-A57B36D3D2D6";
	protocol="application/pgp-signature";
	micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Sun, 21 Mar 2021 10:55:04 -0500
In-Reply-To: <CAG9XoMR1b6Np445WWS999vuWirmAH7hZEaH1ntPBEbiHJ4Y-0w@mail.gmail.com>
Cc: Rowan Tommins <rowan.collins@gmail.com>,
 PHP Internals <internals@lists.php.net>
To: Benjamin Morel <benjamin.morel@gmail.com>
References: <f313c9c4-f8a2-0b39-7499-30620d80cecd@gmail.com>
 <CAG9XoMR1b6Np445WWS999vuWirmAH7hZEaH1ntPBEbiHJ4Y-0w@mail.gmail.com>
Subject: Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?
From: ben@benramsey.com (Ben Ramsey)

--Apple-Mail=_DFE42DB5-AF53-497E-93CB-A57B36D3D2D6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Mar 21, 2021, at 09:32, Benjamin Morel <benjamin.morel@gmail.com> =
wrote:
>=20
> On Sun, 21 Mar 2021 at 15:18, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
>> I can see three ways forward:
>>=20
>> A) Raise a deprecation notice in 8.1, and remove in 9.0. Do not =
provide
>> a specific replacement, but recommend people look at iconv() or
>> mb_convert_encoding(). There is precedent for this, such as
>> convert_cyr_string(), but it may frustrate those who are using the
>> functions correctly.
>>=20
>> B) Introduce new names, such as utf8_to_iso_8859_1 and
>> iso_8859_1_to_utf8; immediately make those the primary names in the
>> manual, with utf8_encode / utf8_decode as aliases. Raise deprecation
>> notices for the old names, either immediately or in some future =
release.
>> This gives a smoother upgrade path, but commits us to having these
>> functions as outliers in our standard library.
>>=20
>=20
> Hi, I'm personally fine with A or B, both of which have pros & cons:
>=20
> - A is probably the cleanest way as, as you said, these functions =
should
> never have existed (locked to a single encoding that will only benefit =
a
> portion of users), but that's quite a BC break
> - B has is less of a BC break as it gives users a chance to rename =
their
> function calls, but leaves an oddity in the standard library
>=20
> I'm a bit worried that either way, we'll start seeing some "polyfills"
> appear on Packagist to re-introduce the old functions, but at least =
they
> will be gone from the core.


I prefer option A, and the emergence of userland polyfills doesn=E2=80=99t=
 worry
me. IMO, that=E2=80=99s the right way for the community to handle the BC =
break.

Cheers,
Ben




--Apple-Mail=_DFE42DB5-AF53-497E-93CB-A57B36D3D2D6
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQToXQMR3fpbrPOmEOewLZeYnIwHGwUCYFdsWAAKCRCwLZeYnIwH
G0m9AP9jCcAh08m7X4MuJnHJmgVBkwosdHwww7crePxA/oFMxgD9G6Q8y3XW6OVB
MpoQx3XnHxfNBxyM5+Elvkvfg9oduPA=
=S3LW
-----END PGP SIGNATURE-----

--Apple-Mail=_DFE42DB5-AF53-497E-93CB-A57B36D3D2D6--