Everything

php

RFC [Discussion]: mb_str_pad

php.internals

Niels Dossche

3 years ago

Hello internals

I'm opening the discussion for my RFC to implement mb_str_pad.

RFC: https://wiki.php.net/rfc/mb_str_pad
Implementation pull request: https://github.com/php/php-src/pull/11284

Kind regards
Niels

Rowan Collins

3 years ago

On 20 May 2023 13:53:20 BST, Niels Dossche <dossche.niels@gmail.com> wrote:

>RFC: https://wiki.php.net/rfc/mb_str_pad

Hi Niels,

This seems like a reasonable addition. My only hesitation is that it will share with other mbstring functions the slightly dubious definition of "character" as "code point", rather than "grapheme", when dealing with Unicode strings.

This is most easily demonstrated using combining diacritics, e.g. "Franc\u{0327}ais" is 9 code points long, but visually identical to the 8 code point "Fran\u{00E7}ais" used in your examples. Unicode defines "graphemes" or "grapheme clusters" to better match the common intuition of what a "character" means.

Perhaps we should instead, or also, add a "grapheme_strpad" function to ext/intl?

Regards,

--
Rowan Tommins
[IMSoP]

Niels Dossche

3 years ago

Hi Rowan

On 5/20/23 17:13, Rowan Tommins wrote:

> On 20 May 2023 13:53:20 BST, Niels Dossche <dossche.niels@gmail.com> wrote:
>> RFC: https://wiki.php.net/rfc/mb_str_pad
>
> Hi Niels,
>
> This seems like a reasonable addition. My only hesitation is that it will share with other mbstring functions the slightly dubious definition of "character" as "code point", rather than "grapheme", when dealing with Unicode strings.
>
> This is most easily demonstrated using combining diacritics, e.g. "Franc\u{0327}ais" is 9 code points long, but visually identical to the 8 code point "Fran\u{00E7}ais" used in your examples. Unicode defines "graphemes" or "grapheme clusters" to better match the common intuition of what a "character" means.
>

Thanks for your insight.

This is a good point. I've added a clarification in the RFC text to make clear the definition of character is code point in this case, consistent with mbstring.

> Perhaps we should instead, or also, add a "grapheme_strpad" function to ext/intl?
>
> Regards,
>

I've added this suggestion to the future scope section.

Kind regards
Niels

Joerg Sowa

3 years ago

Hello,
As this is a new function do you consider any namespace for it? Based on
passed RFC[1] allowing for namespaces in bundled extensions it would be
nice to introduce new functions with namespace. Maybe the namespace could
be voted in the RFC separately?

Kind regards,
Jorg

[1] https://wiki.php.net/rfc/namespaces_in_bundled_extensions

Tim Düsterhus

3 years ago

Hi

On 5/22/23 00:08, Jorg Sowa wrote:

> As this is a new function do you consider any namespace for it? Based on
> passed RFC[1] allowing for namespaces in bundled extensions it would be
> nice to introduce new functions with namespace. Maybe the namespace could
> be voted in the RFC separately?
> […]
> [1] https://wiki.php.net/rfc/namespaces_in_bundled_extensions

As per that RFC:

>  When adding new symbols to existing extensions, it is more important to be consistent with existing symbols than to follow the namespacing guidelines.

Best regards
Tim Düsterhus

Niels Dossche

3 years ago

Hi

On 5/22/23 00:08, Jorg Sowa wrote:

> Hello,
> As this is a new function do you consider any namespace for it? Based on
> passed RFC[1] allowing for namespaces in bundled extensions it would be
> nice to introduce new functions with namespace. Maybe the namespace could
> be voted in the RFC separately?

Tim already answered the first question, and I agree with his answer (thanks for looking it up Tim).
Introducing a single function to a new namespace doesn't make much sense to me.
If we'd want to alias the mbstring functions in a namespace then this should go into a separate RFC in my opinion.

>
> Kind regards,
> Jorg
>
> [1] https://wiki.php.net/rfc/namespaces_in_bundled_extensions
>

Kind regards
Niels

Joerg Sowa

3 years ago

It's a reasonable approach. Thanks for clearing it up.

Kind regards,
Jorg

Niels Dossche

3 years ago

Hi internals

I haven't seen more discussion for some time now.
I plan on starting the vote tomorrow evening 20:00 GMT+2, and to end it on June 19 20:00 GMT+2.
Any final comments should be raised now.

Kind regards
Niels