Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119167
Date: Fri, 16 Dec 2022 12:55:46 +0000 (GMT)
To: Jakub Zelenka <bukka@php.net>
cc: "Christoph M. Becker" <cmbecker69@gmx.de>, 
    PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <CAEKnhAH7EvVpvmU7KT_n_59v8b2-CbUaSRHgoOx1shqmt0RtNQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.23.453.2212161249530.462551@singlemalt.home.derickrethans.nl>
References: <alpine.DEB.2.23.453.2212151531360.462551@singlemalt.home.derickrethans.nl> <abe33f13-12ab-9abf-a60a-a1ae5ba03172@gmx.de> <CAEKnhAH7EvVpvmU7KT_n_59v8b2-CbUaSRHgoOx1shqmt0RtNQ@mail.gmail.com>
User-Agent: Alpine 2.23 (DEB 453 2020-06-18)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-204716545-1671195346=:462551"
Subject: Re: [PHP-DEV] Re: [RFC] Unicode Text Processing
From: derick@php.net (Derick Rethans)

--8323329-204716545-1671195346=:462551
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Thu, 15 Dec 2022, Jakub Zelenka wrote:

> On Thu, Dec 15, 2022 at 4:56 PM Christoph M. Becker <cmbecker69@gmx.de>
> wrote:
>=20
> > On 15.12.2022 at 16:34, Derick Rethans wrote:
> >
> > > I have just published an initial draft of the "Unicode Text=20
> > > Processing" RFC, a proposal to have performant unicode text=20
> > > processing always available to PHP users, by introducing a new=20
> > > "Text" class.
> > >
> > > You can find it at:=20
> > > https://wiki.php.net/rfc/unicode_text_processing
> > >
> > > I'm looking forwards to hearing your opinions, additions, and=20
> > > suggestions =E2=80=94 the RFC specifically asks for these in places.
> >
> > | As the implementation requires ICU, this would also mean that PHP=20
> > | depend on the ICU library.
> >
> > Our current stance is that a minimal PHP should be buildable without=20
> > requiring any "non-standard" libraries; this is the reason why we=20
> > bundle PCRE.  If we wanted to stick with that policy, we would need=20
> > to bundle ICU, what might not be the best idea =E2=80=93 it's generally=
 not=20
> > great to have bundled libraries which are still maintained outside=20
> > of php-src, and especially for such huge libraries.
> >
> >
> I agree with this. Bundling ICU doesn't seem like a good idea.=20
> Wouldn't be better to base on something smaller that can be bundled=20
> and does the job? For example NJS and QuickJS use their own=20
> implementations which seem to be fine. Especially=20
> https://github.com/bellard/quickjs/blob/master/libunicode.c seems like=20
> something that we could fork and maintain potentially.

I have no intentions of bundling ICU. That'd be a crazy thing to do.=20
Instead, the current proposal is to make PHP depend on libicu. I realise=20
that this is against our current stance, but considering that 1. most=20
(if not all) Linux distributions ignore our bundled libraries any way as=20
per their policies; 2. libicu is pretty much available everywhere; and=20
3. I am not proposing to require the latest and greatest, I believe we=20
can safely rely on it being available.

I'm not opposed to using something else than ICU Most of the other=20
unicode related libraries that I had a quick look at, either provide a=20
small subset =E2=80=94 either just character properties, or graphemes, none=
 of=20
them also take care of collation/locales and transliteration. I am also=20
weary about some of these library's development and future proofness.=20
ICU won't have these problems.

cheers,
Derick

--=20
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/suppo=
rt
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug
--8323329-204716545-1671195346=:462551--