no way to unignore case ? and no way to know whether the current object is ignoring case ? This makes the API unusable for code wanting to deal with the string in a case sensitive way while accepting an external string object.

Also should we merge this new component in 4.4, which would mean that its first release is already non-experimental ? We are not allowed to have experimental components in LTS versions, per our LTS policy.

no way to unignore case ? and no way to know whether the current object is ignoring case ?

->ignoreCase() applies only to the very next call in the fluent API chain. This should answer both your questions. SeeAbstractString::__clone()

Also should we merge this new component in 4.4

That's something we need to decide indeed. On my side, I think we can make it non-experimental.

and what happens for all methods accepting a string as argument, when passing non-UTF-8 strings to the method on aUtf8String orGraphemeString ?

Regarding the naming, shouldUtf8String be renamed to highlight it is about code points ? AFAIK,GraphemeString also expects the string to be in UTF-8.

Note that these comments are based purely on your PR description. I haven't looked at the code yet.

what happens for all methods accepting a string as argument, when passing non-UTF-8 strings to the method on a Utf8String or GraphemeString ?

anInvalidArgumentException is thrown

should Utf8String be renamed to highlight it is about code points ?

I think UTF-8 is more common vocabulary. The previous PR usedCodePoint indeed, but this is cryptic to many, and doesn't convey the technical encoding scheme (it could use UTF-16BE/LE, etc., nothing would tell). That's why I thinkUtf8String is better.

@nicolas-grekas but the whole component is about UTF-8 strings. AFAICT, even BinaryString is not meant to operate on other encodings, as it does not validate that the string is valid UTF-8 before converting it to other implementations.
Btw, this means that naming the componentString might also be too generic.

BinaryString is not meant to operate on other encodings, as it does not validate that the string is valid UTF-8 before converting it to other implementations

It does, dunno why you think otherwise. If you try to convert a random binary string to UTF-8/Grapheme, you'll get anInvalidArgumentException too.

BinaryString is what it tells: it can handle any binary strings and doesn't care about the encoding, like the native PHP string functions, just using an OOP API.

Thus the name of the component.

To me, this should go as experimental in 5.0.

Definitely supporting this :-) Nice !

Sorry to sound naive, but I can't find in this pull request or the previous one, some brief explanation about when/where should developers use this.

Why/when should we use these classes/methods instead of the normal str_ PHP functions or the mb_str UTF8 functions? Thanks!

Note: I'm not questioning this ... I just want to know where this fits in Symfony developers and Symfony itself. Thanks a lot!

edit: see#33553 (comment)

For your consideration, we could turn these 4 methods:

function ensureLeft(string$prefix):selffunction ensureRight(string$suffix): selffunction padLeft(int$length, string$padStr = ' '): selffunction padRight(int$length, string$padStr = ' '): self

Into these 2 methods if we change the order of the arguments:

function padLeft(string$padStr ='',int$length =null):selffunction padRight(string$padStr = ' ', int $length = null): self

Example:

// BEFORE$s1 =u('lorem')->ensureLeft('abc');// $s1 = 'abclorem'$s2 =u('lorem')->ensureRight('abc');// $s2 = 'loremabc'$s3 =u('lorem')->padLeft(8,'abc');// $s3 = 'abcabcablorem'$s4 =u('lorem')->padRight(8,'abc');// $s4 = 'loremabcabcab'// AFTER$s1 =u('lorem')->padLeft('abc');// $s1 = 'abclorem'$s2 =u('lorem')->padRight('abc');// $s2 = 'loremabc'$s3 =u('lorem')->padLeft('abc',8);// $s3 = 'abcabcablorem'$s4 =u('lorem')->padRight('abc',8);// $s4 = 'loremabcabcab'

when/where should developers use this.

All the time would be fine. e.g.$matches = $string->match('/some-regexp/) is a much more friendly API thanpreg_match('/some-regexp/', $string, $matches) (even more if you consider error handling).

More specifically, I've observed ppl randomly add anmb_ prefix to string functions and magically expect this to fix their encoding issues. This is way too complex right now, doing it correctly is hard. e.g. the Console component deals with utf-8 strings everywhere, it's not pretty. This component would help a lot there. Twig is another place where strings are heavily manipulated and where graphemes are missing actually. It would benefit from the component too.

For your consideration, we could turn these 4 methods:
Into these 2 methods if we change the order of the arguments:

This would be totally unexpected to me. I've seen no other libraries have this API and I'm not sure it works actually.

is in your plans that the methods returning self return a new mutated reference keeping the original one intact? If not/yes, why?

Absolutely! That's critical design concern, not just an implementation detail :) I added a note about it in the desription. Thanks for asking.

@nicolas-grekas thanks for the explanation. It's perfectly clear now!

Another question: some methods are called "left", "right" instead of "prefix/suffix" or "start/end". What happens when the text is Arabic/Persian/Hebrew and uses right-to-text direction? For example,trimRight() removes things at the end of English text ... but at the beginning of Arabic text?

We have been usingtchwork/utf8 in Contao for years and it really is essential if you work with multiple languages beyond the ASCII character range. So +1 for adding this in Symfony and keep up the good work@nicolas-grekas. 👍

It looks amazing. I am curious how it would work together with the rest of the ecosystem. Lets say compatibility with doctrine, intl, symfony/validator, etc? I am sure it will take time before it trickles down to other components, but the future seems bright ;)

Thank you@nicolas-grekas.

Thank you everyone for the reviews, it's been invaluable!
Please send PRs for any follow-ups now!

no way to unignore case ? and no way to know whether the current object is ignoring case ?

->ignoreCase() applies only to the very next call in the fluent API chain. This should answer both your questions. SeeAbstractString::__clone()

I think this answer is incomplete, because there is nothing that stops someone from calling a function likefoo(u("abc")->ignoreCase()), which will then result in every operation in that function being case insensitive unless the function creates a clone of the argument.

This might also happen unintentionally when someone intends to do a lot of case insensitive operations, so they do$a = u("abc")->ignoreCase(); and later afoo($a) is added and strange things might happen.

You might say "Use the code in a wrong way and you will get wrong results", but i still think that this behavior is kind of odd.
I like the style of writing/reading it - that part is ok - but because we cannot overwrite the assignment operator, like in C++, to clear theignoreCase-Flag this can cause some weird side effects.

Maybe have theignoreCase() function return an object of a different class, that is not part of theAbstractString hierarchy and implements a subset of the string functions, so we can at least protect against this with type hints?