Re: [PHP-DEV] Revisiting case-sensitivity in PHP
t; Psr\Log\LoggerInterface" needs to become > "psr\log\LoggerInterface". The problem with this is that it's not > really going to save CPU nor memory because it still has to lowercase > the namespace. > > We could refactor the engine to store the namespace separately from > the type name. This is a lot more work and will increase the size of > some types, which might be difficult at a technical level. > > I can't think of other implementations right now. If nobody can come > up with a better implementation, I think we should consider going with > split-sensitivity on namespaces where it matches the sensitivity of > the thing it is attached to. A namespaced class would have a case > sensitive namespace but a namesped function would still have a case > insensitive one. Hi I'm worried that have an impact on Windows (case-insensitive file system). Even if it's only the Class name. Looks like need to more discussion. Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -
Re: [PHP-DEV][DISCUSSION] Fix mb_trim inaccurate $character
2024年4月15日(月) 17:32 Jorg Sowa : > > Hello Yuya, > I don't think modifying voted RFCs is allowed despite the size of the change. > Moreover, there are no dates of the voting included in the description of the > RFC so it's not clear for visitors when exactly the RFC has been approved. > > Kind regards, > Jorg Hi, Jorg Thank you very much. > I don't think modifying voted RFCs is allowed despite the size of the change. > Moreover, there are no dates of the voting included in the description of the > RFC so it's not clear for visitors when exactly the RFC has been approved. It was not good. Restored original an RFC. Thank you Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -
Re: [PHP-DEV][DISCUSSION] Fix mb_trim inaccurate $character
2024年4月12日(金) 18:32 Nicolas Grekas : > > Hi > > Le jeu. 4 avr. 2024 à 07:41, youkidearitai a écrit : >> >> 2024年4月4日(木) 6:30 Tim Düsterhus : >> > >> > Hi >> > >> > On 4/3/24 10:02, youkidearitai wrote: >> > > Therefore, I think require an RFC, I have written a draft an RFC that >> > > fixes these issues. >> > > https://wiki.php.net/rfc/mb_trim_change_characters >> > >> > I don't think this (widening the type and changing the default value to >> > obtain the *intended* behavior) requires an RFC. It's a bugfix, a bugfix >> > with a slightly larger observable impact than other bugfixes. >> > >> > Best regards >> > Tim Düsterhus >> >> Hi >> Thank you very much for comment. >> >> I would like to discuss this RFC with all of you, as we have not yet >> decided on the correct revision policy. >> I created the RFC for that purpose. >> >> Still waiting for your comments! >> Thank you. >> > > I also don't think this requires an RFC. This is a minor design issue that > has only one possible solution, so there is little to discuss. > > Cheers, > Nicolas Hi, I appreciate late my response. I got it. I modified original an RFC (https://wiki.php.net/rfc/mb_trim) that $character is default parameter. Please point out any problems, I revert it. Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -
Re: [PHP-DEV][RFC][Vote] grapheme_cluster for str_split, grapheme_str_split function
2024年3月26日(火) 23:49 youkidearitai : > > 2024年3月26日(火) 21:58 Peter Kokot : > > > > On Tue, 26 Mar 2024 at 06:41, youkidearitai wrote: > > > > > > Hi, Internals > > > > > > Sorry I mistake. > > > Send again. > > > > > > grapheme_str_split going to "Voting" phase. > > > Vote end is 10th April 00:00 GMT > > > > > > Regards > > > Yuya > > > > > > -- > > > --- > > > Yuya Hamada (tekimen) > > > - https://tekitoh-memdhoi.info > > > - https://github.com/youkidearitai > > > - > > > > And a link is this one for those wondering where to click: > > https://wiki.php.net/rfc/grapheme_str_split > > Thank you very much, Peter. > I forgot link. Thanks again. > > Regards > Yuya > > -- > --- > Yuya Hamada (tekimen) > - https://tekitoh-memdhoi.info > - https://github.com/youkidearitai > - Hi, Internals grapheme_str_split is voting end, result is Yes: 19 No: 0 that is accepted. Thank you for voting and for your discussion and interest in Unicode. I'm going to implements. Cheers Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -
[PHP-DEV] VCS Account Request: youkidearitai
Mainly review and approve pull request to mbstring extension. (probably everything related to Unicode and other character encoding) Alex Dowad (alexdowad) suggested that give to me. https://github.com/php/php-src/pull/13906#issuecomment-2041585626 -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -
Re: [PHP-DEV][DISCUSSION] Fix mb_trim inaccurate $character
2024年4月4日(木) 6:30 Tim Düsterhus : > > Hi > > On 4/3/24 10:02, youkidearitai wrote: > > Therefore, I think require an RFC, I have written a draft an RFC that > > fixes these issues. > > https://wiki.php.net/rfc/mb_trim_change_characters > > I don't think this (widening the type and changing the default value to > obtain the *intended* behavior) requires an RFC. It's a bugfix, a bugfix > with a slightly larger observable impact than other bugfixes. > > Best regards > Tim Düsterhus Hi Thank you very much for comment. I would like to discuss this RFC with all of you, as we have not yet decided on the correct revision policy. I created the RFC for that purpose. Still waiting for your comments! Thank you. Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -
[PHP-DEV][DISCUSSION] Fix mb_trim inaccurate $character
Hi, Internals Found two problem with mb_trim, mb_ltrim and mb_rtrim functions. - https://github.com/php/php-src/issues/13789 - https://github.com/php/php-src/issues/13815 Therefore, I think require an RFC, I have written a draft an RFC that fixes these issues. https://wiki.php.net/rfc/mb_trim_change_characters Feel free to comments on this. Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -
Re: [PHP-DEV][RFC] grapheme cluster for str_split, grapheme_str_split function
2024年3月27日(水) 6:18 Casper Langemeijer : > > On Tue, Mar 26, 2024, at 18:15, Derick Rethans wrote: > > Many of these already exist, such as grapheme_substr. We can't simply change > the behaviour of the already existing functions due to BC reasons. > > > Wow. I feel very stupid. I feel I should have known about grapheme_*, but I > didn't. Oh my, the manual says since PHP 5.3 no less. From what I've seen > around being used, I'm far from the only one though. In an attempt to justify > my own stupidity I searched its use and it's bad. > > Searching on github with language:PHP: > `mb_strlen` 84k files, `grapheme_strlen` 680 > > Then a big number of first 100 of these files are stubs/polyfills/phpstan > metadata. I've seen no framework except Symphony (but they might be further > in the searchresults) > > The grapheme_str_split function, as well as other intl extension functions is > what should replace mbstring really. > > > YES! > > I'm sorry to have wasted your time. If you need someone to help for the > grapheme_ marketing team, let me know. Hi, Casper I think still useful mbstring functions. Because mbstring functions is still valid as a bridge to non-Unicode character codes. We think it makes sense for mbstring to calculate in Unicode code point units. Therefore, I think make sense that separate mbstring functions and grapheme functions. Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -
Re: [PHP-DEV][RFC][Vote] grapheme_cluster for str_split, grapheme_str_split function
2024年3月26日(火) 21:58 Peter Kokot : > > On Tue, 26 Mar 2024 at 06:41, youkidearitai wrote: > > > > Hi, Internals > > > > Sorry I mistake. > > Send again. > > > > grapheme_str_split going to "Voting" phase. > > Vote end is 10th April 00:00 GMT > > > > Regards > > Yuya > > > > -- > > --- > > Yuya Hamada (tekimen) > > - https://tekitoh-memdhoi.info > > - https://github.com/youkidearitai > > - > > And a link is this one for those wondering where to click: > https://wiki.php.net/rfc/grapheme_str_split Thank you very much, Peter. I forgot link. Thanks again. Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -
[PHP-DEV][RFC][Vote] grapheme_cluster for str_split, grapheme_str_split function
Hi, Internals Sorry I mistake. Send again. grapheme_str_split going to "Voting" phase. Vote end is 10th April 00:00 GMT Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -
Re: [PHP-DEV][RFC] grapheme cluster for str_split, grapheme_str_split function
2024年3月26日(火) 5:43 David CARLIER : > > I second this, I think it is a good addition which makes a lot of sense. > > Cheers. > > On Mon, 25 Mar 2024 at 20:36, Ayesh Karunaratne wrote: >> >> > >> > 2024年3月9日(土) 15:26 youkidearitai : >> > > >> > > Hello, Internals >> > > >> > > I created an wiki for `grapheme_str_split` function. >> > > Please see: >> > > https://wiki.php.net/rfc/grapheme_str_split >> > > >> > > I would like to "Under Discussion" section. >> > > >> > > Best Regards >> > > Yuya >> > > >> > > -- >> > > --- >> > > Yuya Hamada (tekimen) >> > > - https://tekitoh-memdhoi.info >> > > - https://github.com/youkidearitai >> > > - >> > >> > Hello, Internals >> > >> > I want to go to "Voting" phase if nothing any comment. >> > I will start at tomorrow(26th) to "Voting" phase. >> > >> > Thank you >> > Yuya >> > >> > -- >> > --- >> > Yuya Hamada (tekimen) >> > - https://tekitoh-memdhoi.info >> > - https://github.com/youkidearitai >> > - >> >> I think it makes sense to add this function, and the PR worked well >> too; It correctly split individual graphemes for all comlex Emojis, >> ZWJs, and those Cthulu texts, and everything else I threw at it. >> >> Good luck for the RFC vote today, hope it passes 爛. Hi, Internals grapheme_str_split going to "Voting" phase. Vote end is 10th April 00:00 GMT Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -
Re: [PHP-DEV][RFC] grapheme cluster for str_split, grapheme_str_split function
2024年3月9日(土) 15:26 youkidearitai : > > Hello, Internals > > I created an wiki for `grapheme_str_split` function. > Please see: > https://wiki.php.net/rfc/grapheme_str_split > > I would like to "Under Discussion" section. > > Best Regards > Yuya > > -- > --- > Yuya Hamada (tekimen) > - https://tekitoh-memdhoi.info > - https://github.com/youkidearitai > - Hello, Internals I want to go to "Voting" phase if nothing any comment. I will start at tomorrow(26th) to "Voting" phase. Thank you Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -
[PHP-DEV][RFC] grapheme cluster for str_split, grapheme_str_split function
Hello, Internals I created an wiki for `grapheme_str_split` function. Please see: https://wiki.php.net/rfc/grapheme_str_split I would like to "Under Discussion" section. Best Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -
Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions
2024年2月21日(水) 9:16 youkidearitai : > > 2024年2月19日(月) 18:55 youkidearitai : > > > > -- Forwarded message ----- > > From: youkidearitai > > Date: 2024年2月19日(月) 18:46 > > Subject: Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions > > To: > > > > > > 2024年2月7日(水) 5:19 youkidearitai : > > > > > > 2024年2月7日(水) 4:49 youkidearitai : > > > > > > > > 2024年2月7日(水) 2:56 Juliette Reinders Folmer > > > > : > > > > > > > > > > On 6-2-2024 3:40, youkidearitai wrote: > > > > > > 2024年2月6日(火) 8:33 Tim Starling : > > > > > >> On 2/2/24 20:27, youkidearitai wrote: > > > > > >> > > > > > >> I see. I'll change mb_ucfirst using titlecase. > > > > > >> > > > > > >> Per my comments a month ago on the GitHub issue , I think it is > > > > > >> much better to use title case for mb_ucfirst() than to use upper > > > > > >> case, since conversion of the first character to upper case has > > > > > >> the effect of corrupting text in the Georgian script, and initial > > > > > >> lower-case ligatures are converted to a form which appears like > > > > > >> two upper case letters. So I'm pleased to see this change to the > > > > > >> PR. > > > > > >> > > > > > >> I would appreciate it if the RFC could also be updated to include > > > > > >> this detail, since my vote depends on whether title case or upper > > > > > >> case will be used. > > > > > >> > > > > > >> -- Tim Starling > > > > > > Hi, Tim > > > > > > > > > > > > Thank you for your comment. > > > > > > I modified to "uses unicode case title" in an RFC. > > > > > > > > > > > > Regards > > > > > > Yuya > > > > > > > > > > > > > > > > Help me out here, but doesn't changing what is actually proposed in an > > > > > RFC **after** the vote has started invalidate the vote ? > > > > > > > > > > Shouldn't the vote be closed/withdrawn and restarted in that case ? > > > > > > > > Hi, Internals. > > > > > > > > Juliette, Thank you for pointing. > > > > I'm mistake. > > > > > > > > I checked the following and it was exactly as I said. > > > > https://wiki.php.net/RFC/voting#voting > > > > > > > > > A valid voting period must be declared when voting is started and > > > > > must not be changed during the vote. > > > > > > > > I broke this rule. In this case, should I return to "Under discussion"? > > > > I apologize to those who voted, admitting lack of discussion, I want > > > > to reorganize. > > > > > > > > Regards > > > > Yuya > > > > > > Hi, Internals. > > > This an RFC is revert to "Under Discussion". > > > > > > https://wiki.php.net/rfc/howto > > > Referenced Section 7.3: > > > > A serious issue with your RFC needs to be addressed: update the status > > > > of your RFC page and its section on https://wiki.php.net/RFC to “Under > > > > Discussion” and continue again from step 5. > > > > > > I would like to wait another two weeks to vote again. > > > Scheduled for February 21st, GMT 00:00 restart voting. > > > > > > Please feel free to comment. > > > > > > I apologize to everyone who voted again. > > > > > > Regards > > > Yuya > > > > > > -- > > > --- > > > Yuya Hamada (tekimen) > > > - https://tekitoh-memdhoi.info > > > - https://github.com/youkidearitai > > > - > > > > I send below message, but kicked by internals. Resend to it. > > > > Hi, Internals. > > This is a reminder. > > > > If nothing another comments, This an RFC restart voting at February > > 21st, GMT 00:00. > > Thank you. > > > > Regards > > Yuya > > > > -- > > --- > > Yuya Hamada (tekimen) > > - https://tekitoh-memdhoi.info > > - https://github.com/youkidearitai > > - > > Hi, Internals. > > Restarted voting phase to Multibyte for ucfirst, lcfirst functions, > mb_ucfirst mb_lcfirst. > https://wiki.php.net/rfc/mb_ucfirst > > Voting end at March 7th 00:00:00 GMT. > > Thanks > Yuya > > -- > --- > Yuya Hamada (tekimen) > - https://tekitoh-memdhoi.info > - https://github.com/youkidearitai > - Hi, Internals The RFC has been ended. Result is accepted (yes: 14, no: 0) Thank you very much for voting. Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -
Re: [PHP-DEV] [Discussion] grapheme cluster for str_split function
2024年3月6日(水) 18:42 Niels Dossche :
>
> On 06/03/2024 01:37, youkidearitai wrote:
> > 2024年3月6日(水) 9:22 youkidearitai :
> >>
> >> Hi, Larry
> >> Hi, Niels
> >>
> >> 2024年3月6日(水) 6:47 Niels Dossche :
> >>>
> >>> Hi Larry
> >>> Hi Yuya
> >>>
> >>> So first of all, I meant the error handling in cases like these:
> >>> https://github.com/php/php-src/pull/13580/files#diff-b8fe038d9d7539694593978bea5605f38dde4bcb6a016865130590e45e23202eR852-R860
> >>> The implementation still returns NULL here, so the signature is still
> >>> incorrect. Either it should return false to match the other functions, or
> >>> throw something and not return a value.
> >>>
> >>> On 05/03/2024 18:40, Larry Garfield wrote:
> >>>> On Tue, Mar 5, 2024, at 7:25 AM, youkidearitai wrote:
> >>>>> 2024年3月5日(火) 5:52 Niels Dossche :
> >>>>>>
> >>>>>> Hi Yuya
> >>>>>>
> >>>>>> This sounds useful.
> >>>>>>
> >>>>>> I do have a question about the function signature:
> >>>>>> function grapheme_str_split(string $string, int $length = 1): array {}
> >>>>>>
> >>>>>> This always returns an array.
> >>>>>> However, looking at your PR it seems you return NULL on failure, but
> >>>>>> the return type in the signature isn't nullable.
> >>>>>> Also, from a quick look, it seems other functions return false instead
> >>>>>> of null on failure. So perhaps the return type should be array|false.
> >>>>>>
> >>>>>> What do you think? :)
> >>>>>>
> >>>>>> Kind regards
> >>>>>> Niels
> >>>>>>
> >>>>>> On 03/03/2024 00:21, youkidearitai wrote:
> >>>>>>> Hi, Internals
> >>>>>>>
> >>>>>>> I noticed PHP does not have grapheme cluster for str_split function.,
> >>>>>>> Until now, you had to use the PCRE function's \X.
> >>>>>>>
> >>>>>>> Therefore, I try create `grapheme_str_split` function.
> >>>>>>> https://github.com/php/php-src/pull/13580
> >>>>>>> It is possible to convert array per emoji and variation selectors
> >>>>>>> using ICU.
> >>>>>>>
> >>>>>>> If it's fine, I'll create an RFC.
> >>>>>>>
> >>>>>>> Regards
> >>>>>>> Yuya
> >>>>>>>
> >>>>>
> >>>>> Hi, Niels
> >>>>>
> >>>>> Thank you for your comment.
> >>>>> Indeed, returns false is make sense.
> >>>>>
> >>>>> Therefore, I changed to returns false when invalid UTF-8 strings.
> >>>>>
> >>>>> Regards
> >>>>> Yuya
> >>>>
> >>>> Many legacy functions return false on error, but that is widely regarded
> >>>> as bad design. Please do not continue bad design.
> >>>
> >>> I agree that returning false on error isn't ideal for exceptional cases,
> >>> that's what exceptions are for.
> >>> Looking at the other grapheme functions makes me wonder though how
> >>> consistent this would be, especially w.r.t. intl_get_error_*() and
> >>> intl_error_name().
> >>>
> >>>>
> >>>> Right now, the best "standard" error handling mechanism available is
> >>>> exceptions. false (or null) can very easily lead to incorrectly using
> >>>> that value as though it were valid, when it's not, which will sometimes
> >>>> cause a fatal error and sometimes cause a security leak.
> >>>>
> >>>> If the input value cannot be logically processed, that's an exception.
> >>>> (Or Error, perhaps.)
> >>>>
> >>>> --Larry Garfield
> >>>
> >>> Kind regards
> >>> Niels
> >>
> >> Thank you so much for advice.
> >> Indeed, This current grapheme* functions seems inconsistent.
> >>
> >> Therefore, it's one thing when returns null, throws any exception.
> >> Shall we do so just for the grapheme_str_split function?
> >>
> >> Regards
> >> Yuya
> >>
> >> --
> >> ---
> >> Yuya Hamada (tekimen)
> >> - https://tekitoh-memdhoi.info
> >> - https://github.com/youkidearitai
> >> -
> >
> > Ah, If throws exception when intl_error*, is required other an RFC?
> > If we make grapheme_str_split's signature is below (include null):
>
> Hi Yuya
>
> If you want to change other grapheme functions with respect to error
> handling, then it requires a separate RFC.
> I think consistency between the functions is important.
>
> >
> > ```
> > function grapheme_str_split(string $string, int $length = 1): array|null {}
> > ```
> >
> > For now, I change signature to `array|null`.
>
> Most others functions return false on error, so I think it should be
> array|false, and the implementation should use RETURN_FALSE instead of
> RETURN_NULL.
>
> >
> > Regards
> > Yuya
> >
> >
>
> Kind regards
> Niels
Hi, Niels
Thank you very much.
I got it. You're right. I couldn't understand well.
I use returns false when something wrong.
I updated Pull Request. Please see.
Regards
Yuya
--
---
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-
Re: [PHP-DEV] Release Managers for PHP 8.4
2024年3月6日(水) 0:41 Jakub Zelenka : > > Hi all, > > It's time to start the process of finding and electing RMs for the next minor > PHP release. > > We are looking for three souls to take on this role. Whomsoever is elected > will be guided and helped by the current, as well as previous RMs and the > excellent documentation in release-process.md [1]. > > Candidates should have a reasonable knowledge of internals, be confident > about merging pull requests without breaking backward compatibility, doing > triage for bugs, liaising with previous release managers, and generally > getting the branch in good shape, as these are among the activities you will > be undertaking as release manager. Ideally, at least one of candidate should > be a core developer that can assess more technical PR's. Other candidates do > not necessarily need to have deep knowledge of internals but should > understand above mentioned points. > > Notably, at least one of the volunteers must be a "veteran" release manager, > meaning they have participated in at least one release of PHP in the past. > The other may be an additional veteran, or more ideally, someone new to the > RM role (in order to increase our supply of veteran RMs). > > Please put your name forward here if you wish to be considered a candidate. > An initial TODO page has been added to the wiki and contains provisional > dates for GA and pre-releases [2]. > > [1] https://github.com/php/php-src/blob/master/docs/release-process.md > [2] https://wiki.php.net/todo/php84 > > Let's all make PHP awesome! > Jakub Zelenka, Eric Mann & Pierrick Charron > Hello, all. I would like to candidacy to Release Manager for PHP 8.4. I created mb_trim functions for since PHP 8.4. There may also be mb_ucfirst and mb_lcfirst functions add to them. I also have other ideas, such as the grapheme_str_split function, and I would like to take care of them if they are included in PHP 8.4. I'm not necessarily familiar with the internals of Zend Engine, but I'm proud that I've taken particular care in maintaining versions. Also, My company (Cybozu Inc.) I currently work for understands my PHP Internals activities and gives me time, so I would like to contribute further. Regards Yuya Hamada -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -
Re: [PHP-DEV] [Discussion] grapheme cluster for str_split function
2024年3月6日(水) 9:22 youkidearitai :
>
> Hi, Larry
> Hi, Niels
>
> 2024年3月6日(水) 6:47 Niels Dossche :
> >
> > Hi Larry
> > Hi Yuya
> >
> > So first of all, I meant the error handling in cases like these:
> > https://github.com/php/php-src/pull/13580/files#diff-b8fe038d9d7539694593978bea5605f38dde4bcb6a016865130590e45e23202eR852-R860
> > The implementation still returns NULL here, so the signature is still
> > incorrect. Either it should return false to match the other functions, or
> > throw something and not return a value.
> >
> > On 05/03/2024 18:40, Larry Garfield wrote:
> > > On Tue, Mar 5, 2024, at 7:25 AM, youkidearitai wrote:
> > >> 2024年3月5日(火) 5:52 Niels Dossche :
> > >>>
> > >>> Hi Yuya
> > >>>
> > >>> This sounds useful.
> > >>>
> > >>> I do have a question about the function signature:
> > >>> function grapheme_str_split(string $string, int $length = 1): array {}
> > >>>
> > >>> This always returns an array.
> > >>> However, looking at your PR it seems you return NULL on failure, but
> > >>> the return type in the signature isn't nullable.
> > >>> Also, from a quick look, it seems other functions return false instead
> > >>> of null on failure. So perhaps the return type should be array|false.
> > >>>
> > >>> What do you think? :)
> > >>>
> > >>> Kind regards
> > >>> Niels
> > >>>
> > >>> On 03/03/2024 00:21, youkidearitai wrote:
> > >>>> Hi, Internals
> > >>>>
> > >>>> I noticed PHP does not have grapheme cluster for str_split function.,
> > >>>> Until now, you had to use the PCRE function's \X.
> > >>>>
> > >>>> Therefore, I try create `grapheme_str_split` function.
> > >>>> https://github.com/php/php-src/pull/13580
> > >>>> It is possible to convert array per emoji and variation selectors
> > >>>> using ICU.
> > >>>>
> > >>>> If it's fine, I'll create an RFC.
> > >>>>
> > >>>> Regards
> > >>>> Yuya
> > >>>>
> > >>
> > >> Hi, Niels
> > >>
> > >> Thank you for your comment.
> > >> Indeed, returns false is make sense.
> > >>
> > >> Therefore, I changed to returns false when invalid UTF-8 strings.
> > >>
> > >> Regards
> > >> Yuya
> > >
> > > Many legacy functions return false on error, but that is widely regarded
> > > as bad design. Please do not continue bad design.
> >
> > I agree that returning false on error isn't ideal for exceptional cases,
> > that's what exceptions are for.
> > Looking at the other grapheme functions makes me wonder though how
> > consistent this would be, especially w.r.t. intl_get_error_*() and
> > intl_error_name().
> >
> > >
> > > Right now, the best "standard" error handling mechanism available is
> > > exceptions. false (or null) can very easily lead to incorrectly using
> > > that value as though it were valid, when it's not, which will sometimes
> > > cause a fatal error and sometimes cause a security leak.
> > >
> > > If the input value cannot be logically processed, that's an exception.
> > > (Or Error, perhaps.)
> > >
> > > --Larry Garfield
> >
> > Kind regards
> > Niels
>
> Thank you so much for advice.
> Indeed, This current grapheme* functions seems inconsistent.
>
> Therefore, it's one thing when returns null, throws any exception.
> Shall we do so just for the grapheme_str_split function?
>
> Regards
> Yuya
>
> --
> ---
> Yuya Hamada (tekimen)
> - https://tekitoh-memdhoi.info
> - https://github.com/youkidearitai
> -
Ah, If throws exception when intl_error*, is required other an RFC?
If we make grapheme_str_split's signature is below (include null):
```
function grapheme_str_split(string $string, int $length = 1): array|null {}
```
For now, I change signature to `array|null`.
Regards
Yuya
--
---
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-
Re: [PHP-DEV] [Discussion] grapheme cluster for str_split function
Hi, Larry
Hi, Niels
2024年3月6日(水) 6:47 Niels Dossche :
>
> Hi Larry
> Hi Yuya
>
> So first of all, I meant the error handling in cases like these:
> https://github.com/php/php-src/pull/13580/files#diff-b8fe038d9d7539694593978bea5605f38dde4bcb6a016865130590e45e23202eR852-R860
> The implementation still returns NULL here, so the signature is still
> incorrect. Either it should return false to match the other functions, or
> throw something and not return a value.
>
> On 05/03/2024 18:40, Larry Garfield wrote:
> > On Tue, Mar 5, 2024, at 7:25 AM, youkidearitai wrote:
> >> 2024年3月5日(火) 5:52 Niels Dossche :
> >>>
> >>> Hi Yuya
> >>>
> >>> This sounds useful.
> >>>
> >>> I do have a question about the function signature:
> >>> function grapheme_str_split(string $string, int $length = 1): array {}
> >>>
> >>> This always returns an array.
> >>> However, looking at your PR it seems you return NULL on failure, but the
> >>> return type in the signature isn't nullable.
> >>> Also, from a quick look, it seems other functions return false instead of
> >>> null on failure. So perhaps the return type should be array|false.
> >>>
> >>> What do you think? :)
> >>>
> >>> Kind regards
> >>> Niels
> >>>
> >>> On 03/03/2024 00:21, youkidearitai wrote:
> >>>> Hi, Internals
> >>>>
> >>>> I noticed PHP does not have grapheme cluster for str_split function.,
> >>>> Until now, you had to use the PCRE function's \X.
> >>>>
> >>>> Therefore, I try create `grapheme_str_split` function.
> >>>> https://github.com/php/php-src/pull/13580
> >>>> It is possible to convert array per emoji and variation selectors using
> >>>> ICU.
> >>>>
> >>>> If it's fine, I'll create an RFC.
> >>>>
> >>>> Regards
> >>>> Yuya
> >>>>
> >>
> >> Hi, Niels
> >>
> >> Thank you for your comment.
> >> Indeed, returns false is make sense.
> >>
> >> Therefore, I changed to returns false when invalid UTF-8 strings.
> >>
> >> Regards
> >> Yuya
> >
> > Many legacy functions return false on error, but that is widely regarded as
> > bad design. Please do not continue bad design.
>
> I agree that returning false on error isn't ideal for exceptional cases,
> that's what exceptions are for.
> Looking at the other grapheme functions makes me wonder though how consistent
> this would be, especially w.r.t. intl_get_error_*() and intl_error_name().
>
> >
> > Right now, the best "standard" error handling mechanism available is
> > exceptions. false (or null) can very easily lead to incorrectly using that
> > value as though it were valid, when it's not, which will sometimes cause a
> > fatal error and sometimes cause a security leak.
> >
> > If the input value cannot be logically processed, that's an exception. (Or
> > Error, perhaps.)
> >
> > --Larry Garfield
>
> Kind regards
> Niels
Thank you so much for advice.
Indeed, This current grapheme* functions seems inconsistent.
Therefore, it's one thing when returns null, throws any exception.
Shall we do so just for the grapheme_str_split function?
Regards
Yuya
--
---
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-
Re: [PHP-DEV] [Discussion] grapheme cluster for str_split function
>
> Hi, Niels
>
> Thank you for your comment.
> Indeed, returns false is make sense.
>
> Therefore, I changed to returns false when invalid UTF-8 strings.
>
> Regards
> Yuya
>
> --
> ---
> Yuya Hamada (tekimen)
> - https://tekitoh-memdhoi.info
> - https://github.com/youkidearitai
> -
Sorry, again.
I checked behavior of mb_str_split function. So Illegal byte sequences
are returned as is.
```
sapi/cli/php -r 'var_dump(mb_str_split("あ\xc2\xf4\x80あ"));'
array(4) {
[0]=>
string(3) "あ"
[1]=>
string(2) "��"
[2]=>
string(1) "�"
[3]=>
string(3) "あ"
}
```
And, I reading ICU document about utext_openUTF8 (below is link):
https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/utext_8h.html#a130e7cba201c4b38799b432eb269f6d5
> Any invalid UTF-8 in the input will be handled in this way: a sequence of
> bytes that has the form of a truncated, but otherwise valid, UTF-8 sequence
> will be replaced by a single unicode replacement character, \uFFFD. Any other
> illegal bytes will each be replaced by a \uFFFD.
Therefore, I think encoding check is not need.
Returns only arrays together with mb_str_split.
Regards
Yuya
--
---
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-
Re: [PHP-DEV] [Discussion] grapheme cluster for str_split function
2024年3月5日(火) 5:52 Niels Dossche :
>
> Hi Yuya
>
> This sounds useful.
>
> I do have a question about the function signature:
> function grapheme_str_split(string $string, int $length = 1): array {}
>
> This always returns an array.
> However, looking at your PR it seems you return NULL on failure, but the
> return type in the signature isn't nullable.
> Also, from a quick look, it seems other functions return false instead of
> null on failure. So perhaps the return type should be array|false.
>
> What do you think? :)
>
> Kind regards
> Niels
>
> On 03/03/2024 00:21, youkidearitai wrote:
> > Hi, Internals
> >
> > I noticed PHP does not have grapheme cluster for str_split function.,
> > Until now, you had to use the PCRE function's \X.
> >
> > Therefore, I try create `grapheme_str_split` function.
> > https://github.com/php/php-src/pull/13580
> > It is possible to convert array per emoji and variation selectors using ICU.
> >
> > If it's fine, I'll create an RFC.
> >
> > Regards
> > Yuya
> >
Hi, Niels
Thank you for your comment.
Indeed, returns false is make sense.
Therefore, I changed to returns false when invalid UTF-8 strings.
Regards
Yuya
--
---
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-
[PHP-DEV] [Discussion] grapheme cluster for str_split function
Hi, Internals I noticed PHP does not have grapheme cluster for str_split function., Until now, you had to use the PCRE function's \X. Therefore, I try create `grapheme_str_split` function. https://github.com/php/php-src/pull/13580 It is possible to convert array per emoji and variation selectors using ICU. If it's fine, I'll create an RFC. Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -
Re: [PHP-DEV] is this thing on?
2024年2月27日(火) 6:13 Tim Düsterhus : > > Hi > > On 2/26/24 10:56, Daniil Gentili wrote: > > even ignoring all the deliverability issues, I don't think using a > > mailing list is a good idea for a modern programming language, seeking > > And neither is GitHub Discussions. When I have the choice between GitHub > Discussions and a mailing list, I'd take a mailing list all day, every > day. See also this previous email of mine: > https://news-web.php.net/php.internals/120010 > > > exclusively github issues and pull request discussions, I believe that > > the mailing list is nothing more than a redundant relic of the past. > > Mailing lists are fine and PHP is not the only project using them. The > Linux kernel successfully uses them, the HAProxy project does as well > and so does Debian. > > Best regards > Tim Düsterhus Hi, Internals There are times when I explore archives (mbstring and character code etc), so it's helpful to have something left in communication form. Therefore a mailing list would be better for that. Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -
Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions
2024年2月19日(月) 18:55 youkidearitai : > > -- Forwarded message - > From: youkidearitai > Date: 2024年2月19日(月) 18:46 > Subject: Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions > To: > > > 2024年2月7日(水) 5:19 youkidearitai : > > > > 2024年2月7日(水) 4:49 youkidearitai : > > > > > > 2024年2月7日(水) 2:56 Juliette Reinders Folmer > > > : > > > > > > > > On 6-2-2024 3:40, youkidearitai wrote: > > > > > 2024年2月6日(火) 8:33 Tim Starling : > > > > >> On 2/2/24 20:27, youkidearitai wrote: > > > > >> > > > > >> I see. I'll change mb_ucfirst using titlecase. > > > > >> > > > > >> Per my comments a month ago on the GitHub issue , I think it is much > > > > >> better to use title case for mb_ucfirst() than to use upper case, > > > > >> since conversion of the first character to upper case has the effect > > > > >> of corrupting text in the Georgian script, and initial lower-case > > > > >> ligatures are converted to a form which appears like two upper case > > > > >> letters. So I'm pleased to see this change to the PR. > > > > >> > > > > >> I would appreciate it if the RFC could also be updated to include > > > > >> this detail, since my vote depends on whether title case or upper > > > > >> case will be used. > > > > >> > > > > >> -- Tim Starling > > > > > Hi, Tim > > > > > > > > > > Thank you for your comment. > > > > > I modified to "uses unicode case title" in an RFC. > > > > > > > > > > Regards > > > > > Yuya > > > > > > > > > > > > > Help me out here, but doesn't changing what is actually proposed in an > > > > RFC **after** the vote has started invalidate the vote ? > > > > > > > > Shouldn't the vote be closed/withdrawn and restarted in that case ? > > > > > > Hi, Internals. > > > > > > Juliette, Thank you for pointing. > > > I'm mistake. > > > > > > I checked the following and it was exactly as I said. > > > https://wiki.php.net/RFC/voting#voting > > > > > > > A valid voting period must be declared when voting is started and must > > > > not be changed during the vote. > > > > > > I broke this rule. In this case, should I return to "Under discussion"? > > > I apologize to those who voted, admitting lack of discussion, I want > > > to reorganize. > > > > > > Regards > > > Yuya > > > > Hi, Internals. > > This an RFC is revert to "Under Discussion". > > > > https://wiki.php.net/rfc/howto > > Referenced Section 7.3: > > > A serious issue with your RFC needs to be addressed: update the status of > > > your RFC page and its section on https://wiki.php.net/RFC to “Under > > > Discussion” and continue again from step 5. > > > > I would like to wait another two weeks to vote again. > > Scheduled for February 21st, GMT 00:00 restart voting. > > > > Please feel free to comment. > > > > I apologize to everyone who voted again. > > > > Regards > > Yuya > > > > -- > > --- > > Yuya Hamada (tekimen) > > - https://tekitoh-memdhoi.info > > - https://github.com/youkidearitai > > - > > I send below message, but kicked by internals. Resend to it. > > Hi, Internals. > This is a reminder. > > If nothing another comments, This an RFC restart voting at February > 21st, GMT 00:00. > Thank you. > > Regards > Yuya > > -- > --- > Yuya Hamada (tekimen) > - https://tekitoh-memdhoi.info > - https://github.com/youkidearitai > - Hi, Internals. Restarted voting phase to Multibyte for ucfirst, lcfirst functions, mb_ucfirst mb_lcfirst. https://wiki.php.net/rfc/mb_ucfirst Voting end at March 7th 00:00:00 GMT. Thanks Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -
Fwd: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions
-- Forwarded message - From: youkidearitai Date: 2024年2月19日(月) 18:46 Subject: Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions To: 2024年2月7日(水) 5:19 youkidearitai : > > 2024年2月7日(水) 4:49 youkidearitai : > > > > 2024年2月7日(水) 2:56 Juliette Reinders Folmer > > : > > > > > > On 6-2-2024 3:40, youkidearitai wrote: > > > > 2024年2月6日(火) 8:33 Tim Starling : > > > >> On 2/2/24 20:27, youkidearitai wrote: > > > >> > > > >> I see. I'll change mb_ucfirst using titlecase. > > > >> > > > >> Per my comments a month ago on the GitHub issue , I think it is much > > > >> better to use title case for mb_ucfirst() than to use upper case, > > > >> since conversion of the first character to upper case has the effect > > > >> of corrupting text in the Georgian script, and initial lower-case > > > >> ligatures are converted to a form which appears like two upper case > > > >> letters. So I'm pleased to see this change to the PR. > > > >> > > > >> I would appreciate it if the RFC could also be updated to include this > > > >> detail, since my vote depends on whether title case or upper case will > > > >> be used. > > > >> > > > >> -- Tim Starling > > > > Hi, Tim > > > > > > > > Thank you for your comment. > > > > I modified to "uses unicode case title" in an RFC. > > > > > > > > Regards > > > > Yuya > > > > > > > > > > Help me out here, but doesn't changing what is actually proposed in an > > > RFC **after** the vote has started invalidate the vote ? > > > > > > Shouldn't the vote be closed/withdrawn and restarted in that case ? > > > > Hi, Internals. > > > > Juliette, Thank you for pointing. > > I'm mistake. > > > > I checked the following and it was exactly as I said. > > https://wiki.php.net/RFC/voting#voting > > > > > A valid voting period must be declared when voting is started and must > > > not be changed during the vote. > > > > I broke this rule. In this case, should I return to "Under discussion"? > > I apologize to those who voted, admitting lack of discussion, I want > > to reorganize. > > > > Regards > > Yuya > > Hi, Internals. > This an RFC is revert to "Under Discussion". > > https://wiki.php.net/rfc/howto > Referenced Section 7.3: > > A serious issue with your RFC needs to be addressed: update the status of > > your RFC page and its section on https://wiki.php.net/RFC to “Under > > Discussion” and continue again from step 5. > > I would like to wait another two weeks to vote again. > Scheduled for February 21st, GMT 00:00 restart voting. > > Please feel free to comment. > > I apologize to everyone who voted again. > > Regards > Yuya > > -- > --- > Yuya Hamada (tekimen) > - https://tekitoh-memdhoi.info > - https://github.com/youkidearitai > - I send below message, but kicked by internals. Resend to it. Hi, Internals. This is a reminder. If nothing another comments, This an RFC restart voting at February 21st, GMT 00:00. Thank you. Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -
Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions
2024年2月7日(水) 12:56 Tim Starling :
>
> On 7/2/24 13:43, Ayesh Karunaratne wrote:
> >
> > Hi Tim,
> > Now that the RFC is restarted, could you mention some examples in
> > Georgian that might be good test cases?
> >
> > I was thinking there might be some good test cases in Turkish, but
> > couldn't find any. The RFC has examples
> > (https://github.com/php/php-src/pull/13161) in Vietnamese, but they
> > are correct for both "uppercase first character" and titlecase
> > conversions.
>
> Any Georgian word would do. Your ASCII test case is "abc". The
> Georgian equivalent for that would be "აბგ" (ani bani gani, U+10D0
> U+10D1 U+10D2) which should remain the same after passing through
> mb_ucfirst(). Compare mb_strtoupper("აბგ") -> "ᲐᲑᲒ" (U+1C90 U+1C91
> U+1C92).
>
> On the task I mentioned that ligatures are also affected. I gave the
> example mb_ucfirst("lj") -> "Lj", that is, U+01C9 -> U+01C8. You could
> add a test case for that. Compare mb_strtoupper("lj") -> "LJ" (U+01C7).
>
> To repeat my rationale -- we can view ucfirst() either through a
> technical lens (convert the first character of a string to upper case)
> or through a natural language lens (convert a string to sentence case,
> with the initial letter capitalised per local conventions). I am
> arguing to make mb_ucfirst() be a natural language extension of
> ucfirst(), because applying the technical extension would produce
> results that look quite jarring in a natural language context.
>
> There are some edge cases which are not quite right. To really do a
> good job, a new case map will be needed. But if we document it as
> being for natural language, and set the right expectations, we can fix
> the edge cases later.
>
> -- Tim Starling
>
Hi, Tim
Thank you for Georgian test case.
I added to test case.
If other any comments, please feel free.
Regards
Yuya
--
---
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions
2024年2月7日(水) 4:49 youkidearitai : > > 2024年2月7日(水) 2:56 Juliette Reinders Folmer > : > > > > On 6-2-2024 3:40, youkidearitai wrote: > > > 2024年2月6日(火) 8:33 Tim Starling : > > >> On 2/2/24 20:27, youkidearitai wrote: > > >> > > >> I see. I'll change mb_ucfirst using titlecase. > > >> > > >> Per my comments a month ago on the GitHub issue , I think it is much > > >> better to use title case for mb_ucfirst() than to use upper case, since > > >> conversion of the first character to upper case has the effect of > > >> corrupting text in the Georgian script, and initial lower-case ligatures > > >> are converted to a form which appears like two upper case letters. So > > >> I'm pleased to see this change to the PR. > > >> > > >> I would appreciate it if the RFC could also be updated to include this > > >> detail, since my vote depends on whether title case or upper case will > > >> be used. > > >> > > >> -- Tim Starling > > > Hi, Tim > > > > > > Thank you for your comment. > > > I modified to "uses unicode case title" in an RFC. > > > > > > Regards > > > Yuya > > > > > > > Help me out here, but doesn't changing what is actually proposed in an > > RFC **after** the vote has started invalidate the vote ? > > > > Shouldn't the vote be closed/withdrawn and restarted in that case ? > > Hi, Internals. > > Juliette, Thank you for pointing. > I'm mistake. > > I checked the following and it was exactly as I said. > https://wiki.php.net/RFC/voting#voting > > > A valid voting period must be declared when voting is started and must not > > be changed during the vote. > > I broke this rule. In this case, should I return to "Under discussion"? > I apologize to those who voted, admitting lack of discussion, I want > to reorganize. > > Regards > Yuya Hi, Internals. This an RFC is revert to "Under Discussion". https://wiki.php.net/rfc/howto Referenced Section 7.3: > A serious issue with your RFC needs to be addressed: update the status of > your RFC page and its section on https://wiki.php.net/RFC to “Under > Discussion” and continue again from step 5. I would like to wait another two weeks to vote again. Scheduled for February 21st, GMT 00:00 restart voting. Please feel free to comment. I apologize to everyone who voted again. Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions
2024年2月7日(水) 2:56 Juliette Reinders Folmer : > > On 6-2-2024 3:40, youkidearitai wrote: > > 2024年2月6日(火) 8:33 Tim Starling : > >> On 2/2/24 20:27, youkidearitai wrote: > >> > >> I see. I'll change mb_ucfirst using titlecase. > >> > >> Per my comments a month ago on the GitHub issue , I think it is much > >> better to use title case for mb_ucfirst() than to use upper case, since > >> conversion of the first character to upper case has the effect of > >> corrupting text in the Georgian script, and initial lower-case ligatures > >> are converted to a form which appears like two upper case letters. So I'm > >> pleased to see this change to the PR. > >> > >> I would appreciate it if the RFC could also be updated to include this > >> detail, since my vote depends on whether title case or upper case will be > >> used. > >> > >> -- Tim Starling > > Hi, Tim > > > > Thank you for your comment. > > I modified to "uses unicode case title" in an RFC. > > > > Regards > > Yuya > > > > Help me out here, but doesn't changing what is actually proposed in an > RFC **after** the vote has started invalidate the vote ? > > Shouldn't the vote be closed/withdrawn and restarted in that case ? Hi, Internals. Juliette, Thank you for pointing. I'm mistake. I checked the following and it was exactly as I said. https://wiki.php.net/RFC/voting#voting > A valid voting period must be declared when voting is started and must not be > changed during the vote. I broke this rule. In this case, should I return to "Under discussion"? I apologize to those who voted, admitting lack of discussion, I want to reorganize. Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions
2024年2月6日(火) 8:33 Tim Starling : > > On 2/2/24 20:27, youkidearitai wrote: > > I see. I'll change mb_ucfirst using titlecase. > > Per my comments a month ago on the GitHub issue , I think it is much better > to use title case for mb_ucfirst() than to use upper case, since conversion > of the first character to upper case has the effect of corrupting text in the > Georgian script, and initial lower-case ligatures are converted to a form > which appears like two upper case letters. So I'm pleased to see this change > to the PR. > > I would appreciate it if the RFC could also be updated to include this > detail, since my vote depends on whether title case or upper case will be > used. > > -- Tim Starling Hi, Tim Thank you for your comment. I modified to "uses unicode case title" in an RFC. Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions
2024年2月2日(金) 18:15 Ayesh Karunaratne : >> >> On Fri, Feb 2, 2024 at 2:00 AM youkidearitai >> wrote: >> >> > Hi, Internals >> > >> > I have just opened the voting "Multibyte ucfirst and lcfirst functions" >> > RFC. >> > https://wiki.php.net/rfc/mb_ucfirst >> > >> > Voting will be open until February 26th, 2024 at 01:00 UTC. >> > >> > Cheers >> > Yuya >> > >> > -- >> > --- >> > Yuya Hamada (tekimen) >> > - https://tekitoh-memdhoi.info >> > - https://github.com/youkidearitai >> > - >> > >> > -- >> > PHP Internals - PHP Runtime Development Mailing List >> > To unsubscribe, visit: https://www.php.net/unsub.php >> > >> > >> In the proposal part is mentioned "From what I've researched with Unicode, >> it may not behave as expected in some languages. In that case, please deal >> with it in userland.". If my understanding here is wrong, please correct >> me. ucfirst and lcfirst are to uppercase/lowercase the first character of a >> word for characters that have an upper/lower case variant. Whether or not a >> word _should_ have an uppercase or lower case character is not important >> and currently doesn't behave in such a way for ucfirst and lcfirst. To me >> this isn't unexpected behavior, that's exactly how I would expect it to >> behave. > > > I think the author refers to the potential edge cases in certain Unicode > mappings. There isn't an ucfirst mapping, but there are uppercase and > titlecase mappings. > > Unicode titlecase mapping is different from uppercase mapping. This PR seems > to be using uppercase mapping. This should not matter for a vast majority of > characters, except for ligatures and digraphs. > > I'm not at all and expert in these edge cases, but I just wanted to put my > two cents forth that I personally think using titlecase mapping on the first > word would be the more appropriate approach. > > Thank you. Hi, Thank you for reply. > > I think the author refers to the potential edge cases in certain Unicode > mappings. There isn't an ucfirst mapping, but there are uppercase and > titlecase mappings. > Yes, Ayesh is right. This is a text that is the result of investigating edge cases. > I'm not at all and expert in these edge cases, but I just wanted to put my > two cents forth that I personally think using titlecase mapping on the first > word would be the more appropriate approach. I see. I'll change mb_ucfirst using titlecase. Thank you. Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions
Hi, Internals I have just opened the voting "Multibyte ucfirst and lcfirst functions" RFC. https://wiki.php.net/rfc/mb_ucfirst Voting will be open until February 26th, 2024 at 01:00 UTC. Cheers Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Under Discussion] mb_ucfirst and mb_lcfirst
Hi, Larry > Minor typo note: "o do this will implobe the readability" > > > According to research about Unicode, some (natural) lanugage doesn't may > > expected behavior, please deal with it in userland if any wrong. Because > > (natural) languages is a lot of exists, it is difficult to deal in mbstring. > > This paragraph is... very confusing. I think it's a translation issue, > because I can't tell what you're saying here as the grammar doesn't work. I > recommend discussing with a native speaker to help clarify this paragraph. > > I'm fine with the concept, but the text needs to be tightened. > Thank you very much for pointing that out. I use translate Google translate, and add example. If this is difficult to understand, ask someone who knows English. -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] [Under Discussion] mb_ucfirst and mb_lcfirst
Hi, Internals I starting discussion to mb_ucfirst and mb_lcfirst. RFC Link: https://wiki.php.net/rfc/mb_ucfirst Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV][RFC] Multibyte for ucfirst function
Hi, Internals I have been create an RFC: https://wiki.php.net/rfc/mb_ucfirst Please feel free comment. Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Multibyte for ucfirst function
Hi, Internals I'm try creating a new RFC that add mb_ucfirst and mb_lcfirst functions. Draft is here: https://github.com/php/php-src/issues/13075#issuecomment-1893012382 If any wrong, please feel free comment. Cheers Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Multibyte for ucfirst function
Hi, Internals
We got feature request for "Multibyte for ucfirst function".
https://github.com/php/php-src/issues/13075
I think make sense for implement this function, but I don't know well
about not-latin language.
I have a question.
gnutix san pick up sample to below:
https://stackoverflow.com/questions/2517947/ucfirst-function-for-multibyte-character-encodings/58915632#58915632
```
function mb_ucfirst(string $str, ?string $encoding = null): string
{
return mb_strtoupper(mb_substr($str, 0, 1, $encoding), $encoding)
. mb_substr($str, 1, null, $encoding);
}
```
mb_strtoupper supports not-latin language, Therefore, that means
effect ucfirst not-latin language.
Manual of mb_strtoupper is shows example #2 not-latin language.
https://www.php.net/manual/en/function.mb-strtoupper.php#refsect1-function.mb-strtoupper-examples
What do we think? Feel free to comment.
Cheers for new year.
Yuya
--
---
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistency mbstring functions
cern is that this quirk can cause security issues in > > user code. I came across this in the first place when discovering an > > exploitable security vulnerability in an application. From my point of > > view, this is not only about inconsistent behavior but also violates > > the documentation for specific functions like mb_strstr. I agree that > > a lot of mbstring operations should not be used on invalid strings, > > and an exception seems to be an appropriate answer despite the huge BC > > impact. > > I think it is only a security issue when people accidentally think > mb_* functions should be used if it is available. I've seen people do > mb_strlen() on binary data, for example, not realizing the differences > between mb_strlen and strlen. Or using mb_* functions and then passing > them off to cryptographic functions. > > Robert Landers > Software Engineer > Utrecht NL > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > Hi, Internals. Sorry if I'm off topic. I don't know if it will be helpful, Japanese mbstring user if use these mb_* functions, we use mb_check_encoding. If character encoding is invalid, then occur error. ``` https://tekitoh-memdhoi.info - https://github.com/youkidearitai - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistency mbstring functions
2023年12月1日(金) 18:48 G. P. B. :
>
> On Fri, 1 Dec 2023 at 09:31, Stefan Schiller via internals <
> internals@lists.php.net> wrote:
>
> > Hi,
> >
> > I would like to raise attention to an inconsistency in how mbstring
> > functions handle invalid multibyte sequences. When, for example,
> > mb_strpos encounters a UTF-8 leading byte, it tries to parse the
> > following continuation bytes until the full byte sequence is read. If
> > an invalid byte is encountered, all previously read bytes are
> > considered one character, and the parsing is started over again at the
> > invalid byte. Let's consider the following example:
> >
> > mb_strpos("\xf0\x9fABCD", "B"); // int(2)
> >
> > The leading byte 0xf0 initiates a 4-byte UTF-8 sequence. The following
> > byte (0x9f) is a valid continuation byte. The next byte (0x41) is not
> > a valid continuation byte. Thus, 0xf0 and 0x9f are considered one
> > character, and 0x41 is regarded as another character. Accordingly, the
> > resulting index of "B" is 2.
> >
> > On the other hand, mb_substr, for example, simply skips over
> > continuation bytes when encountering a leading byte. Let's consider
> > the following example, which uses mb_substr to cut the first two
> > characters from the string used in the previous example:
> >
> > mb_substr("\xf0\x9fABCD", 2); // string(1) "D"
> >
> > Again, the leading byte 0xf0 initiates a 4-byte UTF-8 sequence. This
> > time, mb_substr just skips over the next three bytes and considers all
> > 4 bytes one character. Next, it continues to process at byte 0x43
> > ("C"), which is regarded as another character. Thus, the resulting
> > string is "D".
> >
> > This inconsistency in handling invalid multibyte sequences not only
> > exists between different functions but also affects single functions.
> > Let's consider the following example, which uses mb_strstr to
> > determine the first occurrence of the string "B" in the same string:
> >
> > mb_strstr("\xf0\x9fABCD", "B"); // string(1) "D"
> >
> > The principle is the same, just in a single function call.
> >
> > This inconsistency may not only lead to an unexpected behavior but can
> > also have a security impact when the affected functions are used to
> > filter input.
> >
> >
> > Best Regards,
> > Stefan Schiller
> >
> > [1]: https://www.php.net/manual/en/function.mb-strpos.php
> > [2]: https://www.php.net/manual/de/function.mb-substr.php
> > [3]: https://www.php.net/manual/de/function.mb-strstr.php
> >
>
> This might have been better to raise as a bug, but in any case I am CCing
> Alex who's the main maintainer of the mbstring extension so he's aware of
> this and can possibly provide some explanations.
>
> Best regards,
>
> Gina P. Banyard
Hi,
> >
> > I would like to raise attention to an inconsistency in how mbstring
> > functions handle invalid multibyte sequences. When, for example,
> > mb_strpos encounters a UTF-8 leading byte, it tries to parse the
> > following continuation bytes until the full byte sequence is read. If
> > an invalid byte is encountered, all previously read bytes are
> > considered one character, and the parsing is started over again at the
> > invalid byte. Let's consider the following example:
> >
> > mb_strpos("\xf0\x9fABCD", "B"); // int(2)
Yes, that's true. Because mb_strpos is convert to UTF-8 in internal.
However, other mbstring function is temporary convert to UTF-32, then
reconvert to original character encoding.
Anyway, I'll wait Alex's reply.
Regards
Yuya
--
---
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ?
Hi, > > PSR also says that code should use spaces instead of tabs. Should PHP > stop parsing code that uses tabs instead of spaces? > > I don't think that PSR has any relevance to this conversation because > it is _too_ opinionated. Sometimes that opinion helps, and sometimes > it gets in the way and stifles innovation and creativity. > The point is not essential. I want to only say that should not deprecate zend.string_encoding. And I say only character code. Please don't miss the point. Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ?
> Many languages like Rust only support UTF-8 > (https://doc.rust-lang.org/reference/input-format.html), and I don't > think any new PHP developers will expect PHP to work with non-UTF8 > encodings in the first place. Hi, PSR-1 is required use UTF-8. https://www.php-fig.org/psr/psr-1/ Files MUST use only UTF-8 without BOM for PHP code. And, Rust is newer than PHP that is very long history. If we were compare in PHP, almost we would compare language same old year. Java, Perl, Ruby and Python etc. (Java's default encoding is UTF-16). Therefore, I think we should stay with PSR-1 "MUST use only UTF-8 without BOM". Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ?
2023年11月29日(水) 21:16 youkidearitai :
>
> 2023年11月29日(水) 20:42 Hans Henrik Bergan :
> >
> > i think Shift_JIS can also be automatically converted to UTF-8, does
> > this seem right?
> > https://github.com/divinity76/php2utf8/commit/6e08c4c16312961170cce821195816a8d24e23f6
> >
>
> Sorry if it's harsh, not right.
> Shift_JIS is very ambiguous, What will we do if SJIS-2004 or SJIS-win comes?
> How do we guess(detect) SJIS-2004, SJIS-win and SJIS-mac?
>
> // Comparison table from https://uic.io/en/charset/compare/shiftjis2004/cp932/
> var_dump("\xfc\x40"); // What is 0xFC40, 騱(SJIS-2004) or 髜(SJIS-win)?
> ?>
>
> In the first place, We **should not** change PHP script character encoding.
> In addition to this, We have to think about various things.
> This is not just a Japanese problem.
>
> --
> ---
> Yuya Hamada (tekimen)
> - https://tekitoh-memdhoi.info
> - https://github.com/youkidearitai
> -
I'm sorry if offend and reposting.
The problem is easy understand.
What do we detect ISO-8859 series?
Regards
Yuya
--
---
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ?
2023年11月29日(水) 20:42 Hans Henrik Bergan :
>
> i think Shift_JIS can also be automatically converted to UTF-8, does
> this seem right?
> https://github.com/divinity76/php2utf8/commit/6e08c4c16312961170cce821195816a8d24e23f6
>
Sorry if it's harsh, not right.
Shift_JIS is very ambiguous, What will we do if SJIS-2004 or SJIS-win comes?
How do we guess(detect) SJIS-2004, SJIS-win and SJIS-mac?
https://uic.io/en/charset/compare/shiftjis2004/cp932/
var_dump("\xfc\x40"); // What is 0xFC40, 騱(SJIS-2004) or 髜(SJIS-win)?
?>
In the first place, We **should not** change PHP script character encoding.
In addition to this, We have to think about various things.
This is not just a Japanese problem.
--
---
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ?
> Use zend.script_encoding=sjis and zend_bultibyte=true
>
> ❯ ~/php82/bin/php -d zend.script_encoding=sjis -d zend.multibyte=true
> deprecate_zend_scriptencoding.php
> array(7) {
> ["biao_hex"]=>
> string(6) "e8a1a8"
> ["zend.multibyte"]=>
> string(1) "1"
> ["zend.script_encoding"]=>
> string(4) "sjis"
> ["zend.detect_unicode"]=>
> string(1) "1"
> ["mbstring.internal_encoding"]=>
> string(0) ""
> ["mbstring.func_overload"]=>
> bool(false)
> ["PHP_VERSION"]=>
> string(5) "8.2.8"
> }
>
Strictly, include internal_encoding.
❯ ~/php82/bin/php -d zend.script_encoding=sjis -d
internal_encoding=sjis -d zend.multibyte=true
deprecate_zend_scriptencoding.php
array(7) {
["biao_hex"]=>
string(4) "955c"
["zend.multibyte"]=>
string(1) "1"
["zend.script_encoding"]=>
string(4) "sjis"
["zend.detect_unicode"]=>
string(1) "1"
["mbstring.internal_encoding"]=>
string(0) ""
["mbstring.func_overload"]=>
bool(false)
["PHP_VERSION"]=>
string(5) "8.2.8"
}
--
---
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ?
2023年11月29日(水) 9:04 Hans Henrik Bergan :
>
> Do you have access to a project actually using Shift_JIS? Interesting!
> I thought they were practically unicorns / non-existent running PHP4,
>
> Can you run
> ```
> var_dump(array(
> "biao_hex" => bin2hex("表"),
> "zend.multibyte" => ini_get("zend.multibyte"),
> "zend.script_encoding" => ini_get("zend.script_encoding"),
> "zend.detect_unicode" => ini_get("zend.detect_unicode"),
> "mbstring.internal_encoding" => ini_get("mbstring.internal_encoding"),
> "mbstring.func_overload" => ini_get("mbstring.func_overload"),
> "PHP_VERSION" => PHP_VERSION,
> ));
> ```
Hi, Hans
I'm trying to above code.
Nothing config:
❯ ~/php82/bin/php deprecate_zend_scriptencoding.php
PHP Parse error: syntax error, unexpected identifier "zend",
expecting ")" in
/Users/youkidearitai/deprecate_zend_scriptencoding.php on line 5
Parse error: syntax error, unexpected identifier "zend", expecting ")"
in /Users/youkidearitai/deprecate_zend_scriptencoding.php on line 5
Use zend.script_encoding=sjis and zend_bultibyte=true
❯ ~/php82/bin/php -d zend.script_encoding=sjis -d zend.multibyte=true
deprecate_zend_scriptencoding.php
array(7) {
["biao_hex"]=>
string(6) "e8a1a8"
["zend.multibyte"]=>
string(1) "1"
["zend.script_encoding"]=>
string(4) "sjis"
["zend.detect_unicode"]=>
string(1) "1"
["mbstring.internal_encoding"]=>
string(0) ""
["mbstring.func_overload"]=>
bool(false)
["PHP_VERSION"]=>
string(5) "8.2.8"
}
Therefore, zend.script_encoding and zend.multibyte is very important.
Regards
Yuya
--
---
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ?
2023年11月29日(水) 8:07 Hans Henrik Bergan : > > @youkidearitai right now the code specifically deals with > - UTF8: removing UTF8 BOM and removing `declare(encoding='UTF-8'); > - UTF16LE/UTF16BE/UTF32LE/UTF32BE: converting to UTF8 removing the BOM > and removing declare(encoding='...') > - ISO-8859-1: converting to UTF-8 and removing > declare(encoding='ISO-8859-1'), i couldn't really find information on > a ISO-8859-1 BOM, so to the best of my knowledge it does not exist > > it does not deal with any other encodings as of writing, but more can > be added if needed. > Hi, Hans I see. I understand the argument. At least, Japanese character encoding seems not using declare(encoding=...). Probably, we use zend_encoding implicitly. If delete zend_encoding, In SJIS (Shift_JIS) probably will occur 5c problem. For example is below: $val = "表"; // 表 is 0x955c, script see 0x5c22, therefore, Throw on Parse Error Please see about 5c problem https://blog.kano.ac/archive/posts/1654_5c-problem/ I would like to maintain backwards compatibility. zend_encoding seems can't delete. Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ?
2023年11月29日(水) 7:41 Hans Henrik Bergan : > > btw if we come to some consensus to my php2utf8.php script is actually > worthwhile to expand on, i can volunteer to add more encodings (SJIS, > BIG5, anything supported by mbstring), > but it wouldn't surprise me if a better approach exist and the script > should be rewritten entirely~ > > >add that what's special about UTF-8 isn't that it's "fixed-endian". > > should've added this to the last post, but the "zend.detect_unicode" > ini-option is specifically to scan for BOMs, and BOMs are > significantly less useful in fixed-endian encodings (like UTF8) than > bi-endian encodings (like UTF16/UTF32) ^^ > > On Tue, 28 Nov 2023 at 21:47, Hans Henrik Bergan wrote: > > > > > What is the migration path for legacy code that use those directives? > > > > The migration path is to convert the legacy-encoding PHP files to UTF-8. > > Luckily this can be largely automated, here is my attempt: > > https://github.com/divinity76/php2utf8/blob/main/src/php2utf8.php > > but that code definitely needs some proof-reading and additions - idk > > if the approach used is even a good approach, it was just the first i > > could think of, feel free to write one from scratch > > > > > > >Can you share a little more details about how this works? > > > > I hope someone else can do that, but it allows PHP to parse and > > execute scripts not written in UTF-8 and scripts utilizing > > BOM/byte-order-masks. > > > > >add that what's special about UTF-8 isn't that it's "fixed-endian". > > > > one of multiple good things about UTF-8 is that it's fixed-endian, and > > UTF8 don't need a BOM to specify endianess (unlike UTF16 and UTF32 > > which are bi-endian, and a BOM helps identify endianess used~) > > > > >If the solution is as easy as just converting the encoding of the > > source file, then why did we even need to have this setting at all? > > Why did PHP parser support encodings that demanded the introduction of > > > > I've read your question but don't have an answer to it, hopefully > > someone else knows. > > > > > > On Tue, 28 Nov 2023 at 21:09, Claude Pache wrote: > > > > > > > > > > > > > Le 28 nov. 2023 à 20:56, Kamil Tekiela a écrit : > > > > > > > >> Convert your PHP source files to UTF-8. > > > > > > > > If the solution is as easy as just converting the encoding of the > > > > source file, then why did we even need to have this setting at all? > > > > Why did PHP parser support encodings that demanded the introduction of > > > > this declare? > > > > > > It is not necessary as simple: because your code base may contain literal > > > strings, and changing the encoding of the source file will effectively > > > change the contents of the strings. > > > > > > —Claude > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > Hi, Hans Is this convert PHP code from any encoding to UTF-8? If correct, PHP code is coded various character encoding, It is very difficult. This is because it is not necessarily implemented in UTF-8. In the world, we have many character encoding. PHP code will be difficult to unify. Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV][VOTE][RFC] Add multibyte trim function mb_trim, mb_ltrim and mb_rtrim
2023年11月19日(日) 5:11 mickmackusa : > Can you please clear up some ambiguity for me regarding mb_trim()? > > Is it true that the .. character range syntax will not be supported at all or > is it merely that that syntax will not be allowed when one of the range > limits includes a multibyte character? > > Is a mix of a single byte range plus individual multibyte characters allowed? > > If .. is attempted, will it be silently interpretted as two literal dots or > will some kind of Notice be issued? > > I want to keep https://stackoverflow.com/a/72865139/2943403 accurate and up > to date. Hi, Yes, mb_trim series is not support ".." notation. ".." is processed as is. Because single byte character code is also Unicode mapping incompatible. For example, ISO-8859 series, KOI8-R and KOI8-U etc... Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV][VOTE][RFC] Add multibyte trim function mb_trim, mb_ltrim and mb_rtrim
2023年11月3日(金) 0:10 youkidearitai : > > Hi, Internals > > I have just opened voting on the RFC to mb_trim. > Voting started now, and will run until November 17th, 24:00 GMT > > Link: > https://wiki.php.net/rfc/mb_trim#voting > > (It's my first time so please tell me if I'm any wrong) Hi, Internals Voting is now closed. mb_trim, mb_ltrim and mb_rtrim of result is yes:15, no:0. I will soon change from draft pull request (https://github.com/php/php-src/pull/12459) to normal pull request. Regards Yuya. -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Release cycle update
2023年11月11日(土) 8:27 Rowan Tommins :
>
> On 10 November 2023 16:51:57 GMT, Jakub Zelenka wrote:
> >Hello,
> >
> >I would like to propose a new process RFC for updates to PHP release cycle:
> >
> >https://wiki.php.net/rfc/release_cycle_update
>
> Hi,
>
> I started writing a suggestion that you add details to your RFC of what text
> we would remove or change in the existing policy if approved - what you've
> presented so far is like a good commit message, but we probably want a diff
> to go with it.
>
> However, looking at the existing "policy", most of the things you want to
> change aren't actually in it - it doesn't even contain the word "beta". It
> also has parts that are obviously outdated ("Features can use branch(es) if
> necessary" - because the project was using SVN, where branches are costly to
> maintain), parts in the future tense, and even open questions (about who can
> vote for RMs).
>
> So maybe what's really needed is to draft a new copy of the policy document,
> updating or removing those parts that are no longer relevant, and adding a
> timeline for the pre-release phases?
>
> Or possibly there's a different document I should be looking at, and the RFC
> could contain proposed edits to that?
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
Hi, Internals
>From mbstring point of view, PHP 8.0 is last version of not affected
"Major overhaul of mbstring".
For example, PHP 8.0's mb_detect_encoding not affected to below.
- https://github.com/php/php-src/issues/10192
- https://github.com/php/php-src/issues/7871
If PHP 8.0's EOL is one more year, There is a one-year grace period
for upgrades.
Regards
Yuya
--
---
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV][VOTE][RFC] Add multibyte trim function mb_trim, mb_ltrim and mb_rtrim
Hi, Internals I have just opened voting on the RFC to mb_trim. Voting started now, and will run until November 17th, 24:00 GMT Link: https://wiki.php.net/rfc/mb_trim#voting (It's my first time so please tell me if I'm any wrong) Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Add multibyte trim function (mb_trim, mb_ltrim and mb_rtrim)
2023年10月19日(木) 22:33 Niels Dossche : > > Hi Yuya > > On 19/10/2023 13:57, youkidearitai wrote: > > Hi, internals. > > > > 8ctopus san can't send email, so I'm writing new RFC for multibyte > > trim function. > > https://wiki.php.net/rfc/mb_trim > > https://github.com/php/php-src/pull/12459 > > > > I would like to under discussion. > > Thanks for this. > > I have a question about the .. support: > You state "Mapping with other character codes may be incompatible", for one > of the reasons not to support this. > Can you please explain this a bit more? > > Also, I notice at the top of your RFC it still says: "Status: Draft", I think > you forgot to change this. > Similarly, the RFC is not listed under discussion on https://wiki.php.net/rfc. > > > > > Regards. > > Yuya > > > > Kind regards > Niels > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > Hi, Niels. Thank you for your question and Wiki status is changed. > You state "Mapping with other character codes may be incompatible", for one > of the reasons not to support this. > Can you please explain this a bit more? Sure. For example, Japanese character code, If try to match hiragana for each character code, it will end up with different bytes. Hiragana letter matches in UTF-8. [ぁ-ゞ] But other character code is sometimes different. example: EUC-JP [ぁ-ん゛ゝゞ] Sometimes the order is different why I say "Mapping with other character codes may be incompatible". Therefore, I thought it was impossible to express the ".." notation. Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] [Discussion] Add multibyte trim function (mb_trim, mb_ltrim and mb_rtrim)
Hi, internals. 8ctopus san can't send email, so I'm writing new RFC for multibyte trim function. https://wiki.php.net/rfc/mb_trim https://github.com/php/php-src/pull/12459 I would like to under discussion. Regards. Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] RFC Karma Request
Hi, internals. I writing to trim for multibyte support function, mb_trim, mb_ltrim and mb_rtrim. https://github.com/php/php-src/pull/12459 Please give me RFC Karma. Username: youkidearitai Regards. Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Is there any CLA document? Who has the copyright of contributed codes?
2023年10月6日(金) 19:24 丸山雅裕 : > > Dear The PHP Group > > Hello. > > I'm thinking of contributing to PHP within my working hours. > Is there any CLA document? > > My company has some legal check processes before contribution. > The legal department cares of "who has the copyright of contributed codes". > > I suppose The PHP Group has the copyright, is it correct? > > I've read the following documents, but I'm not sure about it. > https://www.php.net/license/index.php > https://www.php.net/license/contrib-guidelines-code.php > https://github.com/php/php-src/blob/master/CONTRIBUTING.md > > Regards, > > Masahiro Maruyama > Hi, I don't know about CLA, but probably this mail is judged to spam. Therefore, I would like send message to welcome that contribute to you. Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] trim support for multibyte spaces
2023年10月2日(月) 23:24 Hans Henrik Bergan :
>
> add a
> void str_dump(const size_t strlen, const char *str)
> {
> printf("string(%zu) \"", strlen);
> fwrite(str, strlen, 1, stdout);
> printf("\"\n");
> }
>
> then replace the string_view stuff with
>
> size_t teststrlen = strlen(teststr);
> str_dump(teststrlen, teststr);
> mb_trim(, , trim_lengths_num, trim_lengths,
> trim_chars);
> str_dump(teststrlen, teststr);
>
> and it should be pure C, i think
>
> On Mon, 2 Oct 2023 at 15:36, youkidearitai wrote:
> >
> > Hi, Hans.
> >
> > Thank you very much for your code. And sorry for late.
> > I confirmed works fine.
> > https://gist.github.com/youkidearitai/0018dee27353c00aebaff3bf57c5b8c6
> >
> > However, this code is C++17, php-src is C code.
> > If you would like contribute, I would like written to C code.
> >
> > Regards
> > Yuya
> >
> > 2023年10月1日(日) 19:46 Hans Henrik Bergan :
> > >
> > > .. probably a bunch of stuff that *could* be optimized or done better,
> > > but one i saw just now is that instead of 2x nested loops and goto,
> > > the outer loop and labels could be removed and the `goto
> > > remove_from_start_continue_2;` could be replaced with `i=-1;` eg
> > >
> > > size_t local_strlen = *strlen;
> > > char *local_str = *str;
> > > for (size_t i = 0; i < trim_lengths_num; ++i)
> > > {
> > > if (local_strlen >= trim_lengths[i] && memcmp(local_str,
> > > trim_chars[i], trim_lengths[i]) == 0)
> > > {
> > > local_strlen -= trim_lengths[i];
> > > local_str += trim_lengths[i];
> > > i = -1;
> > > }
> > > }
> > >
> > > 2x nested loops reduced to 1 loop, and goto removed~
> > >
> > > On Sun, 1 Oct 2023 at 10:43, Hans Henrik Bergan
> > > wrote:
> > > >
> > > > > If have any idea, feel free to comment to me.
> > > >
> > > > i think the C code would look something like
> > > >
> > > >
> > > > void mb_trim(size_t *strlen, char **str, const size_t
> > > > trim_lengths_num, const size_t *trim_lengths, const char **trim_chars)
> > > > {
> > > > size_t local_strlen = *strlen;
> > > > char *local_str = *str;
> > > > for (;;)
> > > > {
> > > > for (size_t i = 0; i < trim_lengths_num; ++i)
> > > > {
> > > > if (local_strlen >= trim_lengths[i] && memcmp(local_str,
> > > > trim_chars[i], trim_lengths[i]) == 0)
> > > > {
> > > > local_strlen -= trim_lengths[i];
> > > > local_str += trim_lengths[i];
> > > > goto remove_from_start_continue_2;
> > > > }
> > > > }
> > > > break;
> > > > remove_from_start_continue_2:;
> > > > }
> > > > for (;;)
> > > > {
> > > > for (size_t i = 0; i < trim_lengths_num; ++i)
> > > > {
> > > > if (local_strlen >= trim_lengths[i] && memcmp(((local_str
> > > > + local_strlen) - trim_lengths[i]), trim_chars[i], trim_lengths[i]) ==
> > > > 0)
> > > > {
> > > > local_strlen -= trim_lengths[i];
> > > > goto remove_from_end_continue_2;
> > > > }
> > > > }
> > > > break;
> > > > remove_from_end_continue_2:;
> > > > }
> > > > memmove(*str, local_str, local_strlen);
> > > > char *newstr = (char *)realloc(*str, local_strlen);
> > > > if (newstr != nullptr)
> > > > {
> > > > *strlen = local_strlen;
> > > > *str = newstr;
> > > > }
> > > > else
> > > > {
> > > > // some error handling
> > > > }
> > > > }
> > > >
> > > > with my simple testcode looking like
> > > >
> > > > int main()
> > > > {
> > > > const char *trim_chars[] = {
> > > > " ",
> > > > "!",
> > > > // utf8 whitespace:
> > >
Re: [PHP-DEV] trim support for multibyte spaces
Hi, Hans.
Thank you very much for your code. And sorry for late.
I confirmed works fine.
https://gist.github.com/youkidearitai/0018dee27353c00aebaff3bf57c5b8c6
However, this code is C++17, php-src is C code.
If you would like contribute, I would like written to C code.
Regards
Yuya
2023年10月1日(日) 19:46 Hans Henrik Bergan :
>
> .. probably a bunch of stuff that *could* be optimized or done better,
> but one i saw just now is that instead of 2x nested loops and goto,
> the outer loop and labels could be removed and the `goto
> remove_from_start_continue_2;` could be replaced with `i=-1;` eg
>
> size_t local_strlen = *strlen;
> char *local_str = *str;
> for (size_t i = 0; i < trim_lengths_num; ++i)
> {
> if (local_strlen >= trim_lengths[i] && memcmp(local_str,
> trim_chars[i], trim_lengths[i]) == 0)
> {
> local_strlen -= trim_lengths[i];
> local_str += trim_lengths[i];
> i = -1;
> }
> }
>
> 2x nested loops reduced to 1 loop, and goto removed~
>
> On Sun, 1 Oct 2023 at 10:43, Hans Henrik Bergan wrote:
> >
> > > If have any idea, feel free to comment to me.
> >
> > i think the C code would look something like
> >
> >
> > void mb_trim(size_t *strlen, char **str, const size_t
> > trim_lengths_num, const size_t *trim_lengths, const char **trim_chars)
> > {
> > size_t local_strlen = *strlen;
> > char *local_str = *str;
> > for (;;)
> > {
> > for (size_t i = 0; i < trim_lengths_num; ++i)
> > {
> > if (local_strlen >= trim_lengths[i] && memcmp(local_str,
> > trim_chars[i], trim_lengths[i]) == 0)
> > {
> > local_strlen -= trim_lengths[i];
> > local_str += trim_lengths[i];
> > goto remove_from_start_continue_2;
> > }
> > }
> > break;
> > remove_from_start_continue_2:;
> > }
> > for (;;)
> > {
> > for (size_t i = 0; i < trim_lengths_num; ++i)
> > {
> > if (local_strlen >= trim_lengths[i] && memcmp(((local_str
> > + local_strlen) - trim_lengths[i]), trim_chars[i], trim_lengths[i]) ==
> > 0)
> > {
> > local_strlen -= trim_lengths[i];
> > goto remove_from_end_continue_2;
> > }
> > }
> > break;
> > remove_from_end_continue_2:;
> > }
> > memmove(*str, local_str, local_strlen);
> > char *newstr = (char *)realloc(*str, local_strlen);
> > if (newstr != nullptr)
> > {
> > *strlen = local_strlen;
> > *str = newstr;
> > }
> > else
> > {
> > // some error handling
> > }
> > }
> >
> > with my simple testcode looking like
> >
> > int main()
> > {
> > const char *trim_chars[] = {
> > " ",
> > "!",
> > // utf8 whitespace:
> > "\xE2\x80\x80", // EN QUAD
> > "\xE2\x80\x81", // EM QUAD
> > "\xE2\x80\x82", // EN SPACE
> > "\xE2\x80\x83", // EM SPACE
> > "\xE2\x80\x84", // THREE-PER-EM SPACE
> > "\xE2\x80\x85", // FOUR-PER-EM SPACE
> > "\xE2\x80\x86", // SIX-PER-EM SPACE
> > };
> > size_t trim_lengths[] = {
> > strlen(trim_chars[0]),
> > strlen(trim_chars[1]),
> > strlen(trim_chars[2]),
> > strlen(trim_chars[3]),
> > strlen(trim_chars[4]),
> > strlen(trim_chars[5]),
> > strlen(trim_chars[6]),
> > strlen(trim_chars[7]),
> > strlen(trim_chars[8]),
> > };
> > size_t trim_lengths_num = sizeof(trim_lengths) /
> > sizeof(trim_lengths[0]);
> > char *teststr = strdup(" ! \xE2\x80\x80\xE2\x80\x81\xE2\x80\x82
> > Hello World ! \xE2\x80\x83\xE2\x80\x84\xE2\x80\x85\xE2\x80\x86 !
> > ");
> > // char *teststr = strdup(" !Hello World !! ");
> > size_t teststrlen = strlen(teststr);
> > std::cout << teststrlen << ": \"" << std::string_view(teststr,
> > teststrlen) << "\"" << std::endl;
> > mb_trim(, , trim_lengths_num, trim_lengths,
> > trim_chars);
> > std::cout << teststrlen << ": \"" << std::s
Re: [PHP-DEV] trim support for multibyte spaces
2023年9月30日(土) 17:42 Saki Takamachi : > > > I also want to trim function of multibyte trim functions. > > > I think that in addition to mb_trim, > mb_ltrim and mb_rtrim are also necessary. > > Hi. > > Having a new option besides regex sounds like a good idea for me, as a user > of a language that benefits from `mb_trim()`. > > Perhaps users are more intuitive about the usefulness of those functions who > have spent more time cleaning "multibyte spaces". Hi Thanks for reply. I'm trying implements to trim for multibyte function. Please give me some time. If have any idea, feel free to comment to me. Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] trim support for multibyte spaces
Hi, Internals. When I was watching https://github.com/php/php-src/issues/9216, I also want to trim function of multibyte trim functions. I think that in addition to mb_trim, mb_ltrim and mb_rtrim are also necessary. What do you think about this? Regards Yuya -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
