Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122579
Precedence: bulk
MIME-Version: 1.0
References: <CAEPPVa2JLAbXh0hVY72srY2FAVywr=s7baafHCF_ggqmyVgAyA@mail.gmail.com>
 <f94eb6cc-007a-4578-83cf-a4dccbec40a4@gmail.com> <CAEPPVa2SNQS_Mggq50eLUSrNaabTnQTgHQ3Y0bjqCa3FgAP4Ew@mail.gmail.com>
 <51122d7e-f218-4243-bbb8-dd59de2165b4@app.fastmail.com> <5817daaf-813c-430e-a12f-32908d1f7ec7@gmail.com>
 <CAEPPVa1ipFNWfVrCTHWJAzRa6rYYFtrfUnzGW0UgsgGyinN7DA@mail.gmail.com>
 <CAEPPVa15nvhqzuxM0EhC8GX0rKK7episAJ124cfb9j0kphCGKQ@mail.gmail.com> <1af7cc52-e571-4975-9361-9cf2247e0cc2@gmail.com>
In-Reply-To: <1af7cc52-e571-4975-9361-9cf2247e0cc2@gmail.com>
Date: Wed, 6 Mar 2024 19:07:09 +0900
Message-ID: <CAEPPVa2kOtj9vVfFsrN_BVKkJFeKY49oSe-yrtscu91EXQtGLA@mail.gmail.com>
Subject: Re: [PHP-DEV] [Discussion] grapheme cluster for str_split function
To: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: youkidearitai@gmail.com (youkidearitai)

2024=E5=B9=B43=E6=9C=886=E6=97=A5(=E6=B0=B4) 18:42 Niels Dossche <dossche.n=
iels@gmail.com>:
>
> On 06/03/2024 01:37, youkidearitai wrote:
> > 2024=E5=B9=B43=E6=9C=886=E6=97=A5(=E6=B0=B4) 9:22 youkidearitai <youkid=
earitai@gmail.com>:
> >>
> >> Hi, Larry
> >> Hi, Niels
> >>
> >> 2024=E5=B9=B43=E6=9C=886=E6=97=A5(=E6=B0=B4) 6:47 Niels Dossche <dossc=
he.niels@gmail.com>:
> >>>
> >>> Hi Larry
> >>> Hi Yuya
> >>>
> >>> So first of all, I meant the error handling in cases like these: http=
s://github.com/php/php-src/pull/13580/files#diff-b8fe038d9d7539694593978bea=
5605f38dde4bcb6a016865130590e45e23202eR852-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=E5=B9=B43=E6=9C=885=E6=97=A5(=E7=81=AB) 5:52 Niels Dossche <do=
ssche.niels@gmail.com>:
> >>>>>>
> >>>>>> Hi Yuya
> >>>>>>
> >>>>>> This sounds useful.
> >>>>>>
> >>>>>> I do have a question about the function signature:
> >>>>>> function grapheme_str_split(string $string, int $length =3D 1): ar=
ray {}
> >>>>>>
> >>>>>> This always returns an array.
> >>>>>> However, looking at your PR it seems you return NULL on failure, b=
ut the return type in the signature isn't nullable.
> >>>>>> Also, from a quick look, it seems other functions return false ins=
tead 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 functi=
on.,
> >>>>>>> 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 rega=
rded as bad design.  Please do not continue bad design.
> >>>
> >>> I agree that returning false on error isn't ideal for exceptional cas=
es, that's what exceptions are for.
> >>> Looking at the other grapheme functions makes me wonder though how co=
nsistent 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 tha=
t 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 exceptio=
n.  (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 hand=
ling, then it requires a separate RFC.
> I think consistency between the functions is important.
>
> >
> > ```
> > function grapheme_str_split(string $string, int $length =3D 1): array|n=
ull {}
> > ```
> >
> > For now, I change signature to `array|null`.
>
> Most others functions return false on error, so I think it should be arra=
y|false, and the implementation should use RETURN_FALSE instead of RETURN_N=
ULL.
>
> >
> > 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


--=20
---------------------------
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-----------------------------