Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119164 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 52014 invoked from network); 16 Dec 2022 05:09:50 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 16 Dec 2022 05:09:50 -0000 To: internals@lists.php.net Date: Thu, 15 Dec 2022 22:09:49 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 References: Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Posted-By: 97.118.80.196 Subject: Re: [RFC] Unicode Text Processing From: dwo@the-wolfeden.com (Daniel Wolfe) Message-ID: On 2022-12-15 8:34 AM, Derick Rethans wrote: > Hi, > > I have just published an initial draft of the "Unicode Text Processing" > RFC, a proposal to have performant unicode text processing always > available to PHP users, by introducing a new "Text" class. > > You can find it at: > https://wiki.php.net/rfc/unicode_text_processing > > I'm looking forwards to hearing your opinions, additions, and > suggestions — the RFC specifically asks for these in places. > > cheers, > Derick > > I love the idea, but we may want to think about using the terms `trimStart` and `trimEnd` instead of `trimLeft` and `trimRight`. Obviously, when the text in the parameter is in a right-to-left language (e.g., Hebrew, Arabic), `trimLeft` and `trimRight` are going to do the opposite of what one may expect from the names of the functions. I know that identifiers like `ltrim` and `rtrim` are longstanding conventions which everyone understands that they **really** mean trimming from the start and end respectively, but this may be an opportunity to amend the inaccuracy. If this ever gets expanded to add padding functions, those should probably be named `padStart` and `padEnd` as well.