Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119175
Message-ID: <24ba312e-5965-8b8c-2506-2db9767aa3d5@bastelstu.be>
Date: Fri, 16 Dec 2022 16:21:46 +0100
MIME-Version: 1.0
Content-Language: en-US
To: Derick Rethans <derick@php.net>, Sara Golemon <pollita@php.net>
Cc: PHP Developers Mailing List <internals@lists.php.net>
References: <alpine.DEB.2.23.453.2212151531360.462551@singlemalt.home.derickrethans.nl>
 <CAESVnVqtSMFCJ_Uxa5Ts7+O=WqGoF+sdrjtcVEUOK2+SHi0z6g@mail.gmail.com>
 <alpine.DEB.2.23.453.2212161327180.462551@singlemalt.home.derickrethans.nl>
In-Reply-To: <alpine.DEB.2.23.453.2212161327180.462551@singlemalt.home.derickrethans.nl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Unicode Text Processing
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

Hi

On 12/16/22 14:28, Derick Rethans wrote:
>> Question 2 is that class.  I know folks have been clammoring for a
>> `String` class for some time and this actually fills that niche quite
>> well.  A part of me wonders if we can overload it a little to provide
>> a psuedo locale of "binary" so that users can, optionally, treat it
>> like a more generalized String class in specific cases, storing a
>> normal `char*` zend_string under the hood in that case.  Possibly as a
>> specialzation tree.
> 
> An alternative could be to just have this as an implementation detail,
> in case the associated locale/collation is C/root. Then nobody needs to
> worry about it, *but* it would mean implementing everything twice. Which
> I am not too keen on, especially because we have such a wide array of
> operations on strings already.
> 

I rather not see this either, because if a 'Text' object may contain 
binary data, the type safety is lost and users cannot rely on "'Text' 
implies valid UTF-8" (see sibling thread).

Best regards
Tim Düsterhus