Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Introduce str_left/right In 8.1 »

Introduce str_left/right In 8.1

php.internals

Unnamed Person

5 years ago
Hello Internals, Since feature freeze for 8.1 is approaching, I want to request two useful string functions that exist in various languages-especially those that run on web servers and used in databases. These are respectively `left();` and `right();` Whether it is VBScript or MySQL, these two functions are available there. When I learnt PHP more than half a decade ago, I wondered why PHP had no functions that provide the same functionality as these two languages provide. Although both of these functions can be created in the userland, I request to build them in core for the following reasons: 1. They are standard functions in various languages. This article <https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(string_f unctions)#left>, available on Wikipedia, compares various languages in regard to string functions and recognizes left and right functions as a general term to make sense of the attitude of these functions. 2. To achieve the effect of these functions, one needs to use `substr();`. If these functions are introduced, it will be clear on the readers' level the actual purpose of the use of that string function. 3. There may be libraries that provide with the similar functionality; why not add this popular function to the core and make it available for everyone to use? IT will not require people to include such heavy libraries to their projects for such little and useful functions. 4. In the recent versions, PHP did include "str_contains", "str_ends_with", "str_starts_with", "array_key_first", and "array_key_last" functions. All of these functions are buildable in the userland, yet they have managed to make place to the core because of their popularity. Why not these two functions? If one has issues with the name choice, this is something that can be discussed. This request also takes inspiration from Kim Hallberg's proposal for `clamp();` function. His email encouraged me to put my word on the table. I am positive that senior developers would provide me with the feedback on my suggestion. I am also positive that my request will be added to 8.1. I thank you all for reading through my message and dropping a word. Best Regards Hamza Ahmad

Girgias

5 years ago
On Wed, 23 Jun 2021 at 15:15, Hamza Ahmad <office.hamzaahmad@gmail.com> wrote:
> Hello Internals, > > Since feature freeze for 8.1 is approaching, I want to request two useful > string functions that exist in various languages-especially those that run > on web servers and used in databases. These are respectively `left();` and > `right();` > > Whether it is VBScript or MySQL, these two functions are available there. > When I learnt PHP more than half a decade ago, I wondered why PHP had no > functions that provide the same functionality as these two languages > provide. > > Although both of these functions can be created in the userland, I request > to build them in core for the following reasons: > 1. They are standard functions in various languages. This article > < > https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(string_f > unctions)#left>, available on Wikipedia, compares various languages in > regard to string functions and recognizes left and right functions as a > general term to make sense of the attitude of these functions. > 2. To achieve the effect of these functions, one needs to use `substr();`. > If these functions are introduced, it will be clear on the readers' level > the actual purpose of the use of that string function. > 3. There may be libraries that provide with the similar functionality; why > not add this popular function to the core and make it available for > everyone > to use? IT will not require people to include such heavy libraries to their > projects for such little and useful functions. > 4. In the recent versions, PHP did include "str_contains", "str_ends_with", > "str_starts_with", "array_key_first", and "array_key_last" functions. All > of > these functions are buildable in the userland, yet they have managed to > make > place to the core because of their popularity. Why not these two functions? > > If one has issues with the name choice, this is something that can be > discussed. > > This request also takes inspiration from Kim Hallberg's proposal for > `clamp();` function. His email encouraged me to put my word on the table. > > I am positive that senior developers would provide me with the feedback on > my suggestion. I am also positive that my request will be added to 8.1. I > thank you all for reading through my message and dropping a word. > > Best Regards > > Hamza Ahmad > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Sorry, but I really don't see the point of these functions. Most other programming languages, by the link you've provided don't have such a function and use either a function similar to substr() or offset ranges. Contrasting this to the clamp() proposal which necessitates multiple function calls to achieve the same result which *could* mean a performance penalty if such a function is in a hot loop (e.g. Machine Learning). To address point 4, yes these convenience functions have been added recently, but they are *extremely* common and their alternatives were rather confusing or cumbersome. And even then there was resistance to add them. All this to say that the burden of maintenance for such a specialized function makes it very unsuitable to be in core. Best regards, George P. Banyard

Sara Golemon

5 years ago
On Wed, Jun 23, 2021 at 9:15 AM Hamza Ahmad <office.hamzaahmad@gmail.com> wrote:
> > Since feature freeze for 8.1 is approaching, I want to request two useful > string functions that exist in various languages-especially those that run > on web servers and used in databases. These are respectively `left();` and > `right();` > >
Sorry, you spent several paragraphs insisting that these are common functions, but you didn't explain what they're meant to actually do. Using some context, I would assume you mean this: function str_left(string $str, int $len): string { return substr($str, 0, $len); } function str_right(string $str, int $len): string { return substr($str, -$len); } If that's the case, then.... why? As you can see, the existing functionality available is trivial to write. You don't even need to know any particular amount of math (which I've been recently informed shouldn't be a prerequisite to writing software -- shakes fist at clouds). Am I misunderstanding what these proposed functions should do, or am I underestimating the difficulty of typing a zero or negative sign on certain keyboards? -Sara

Guilliam Xavier

5 years ago
On Wed, Jun 23, 2021 at 6:49 PM Sara Golemon <pollita@php.net> wrote:
> On Wed, Jun 23, 2021 at 9:15 AM Hamza Ahmad <office.hamzaahmad@gmail.com> > wrote: > > > > > Since feature freeze for 8.1 is approaching, I want to request two useful > > string functions that exist in various languages-especially those that > run > > on web servers and used in databases. These are respectively `left();` > and > > `right();` > > > > > Sorry, you spent several paragraphs insisting that these are > common functions, but you didn't explain what they're meant to actually do. > > Using some context, I would assume you mean this: > > function str_left(string $str, int $len): string { > return substr($str, 0, $len); > } > > function str_right(string $str, int $len): string { > return substr($str, -$len); > } >
I assume the same.
> > If that's the case, then.... why? As you can see, the existing > functionality available is trivial to write. You don't even need to know > any particular amount of math (which I've been recently informed shouldn't > be a prerequisite to writing software -- shakes fist at clouds). > > Am I misunderstanding what these proposed functions should do, or am I > underestimating the difficulty of typing a zero or negative sign on certain > keyboards? >
I think that's more about "semantics" ("conveying intent to readers") than typing... That said, I tend to agree with George (but maybe I'm "too" used to seeing substr()?) Regards,
-- Guilliam Xavier

Mike Schinkel

5 years ago
Replying to both Sara's and G.P.B.'s emails below:
> On Jun 23, 2021, at 12:48 PM, Sara Golemon <pollita@php.net> wrote: > > Using some context, I would assume you mean this: > > function str_left(string $str, int $len): string { > return substr($str, 0, $len); > } > > function str_right(string $str, int $len): string { > return substr($str, -$len); > } > > If that's the case, then.... why? As you can see, the existing > functionality available is trivial to write. > <snip> > Am I misunderstanding what these proposed functions should do, or am I > underestimating the difficulty of typing a zero or negative sign on certain > keyboards?
I can't speak for Hamza, but one reason I can see for why — at least for str_right() — is that using a negative index might not occur to many people. Hell, I even forgot substr() worked that way until you mentioned it. But, since objective evidence is better than opinion, a non-trivial number of people have searched how to get the last 'n' characters from a string in PHP, found the answer, and then went to the effort to upvote it on StackOverflow. If the 90-9-1 rule holds, then that's about 6200 people who have been confused, searched and found the answer here: https://stackoverflow.com/questions/10542310/how-can-i-get-the-last-7-characters-of-a-php-string <https://stackoverflow.com/questions/10542310/how-can-i-get-the-last-7-characters-of-a-php-string> For future people to whom it does not occur that substr() accepts negative arguments, or for people who forget that fact, str_right() would provide an obvious solution that would be easy to find in IDE autocomplete or when scanning the list of functions on PHP.net. At which point it would make sense to also at str_left() for symmetry. That said, my world won't change if these functions are not added, but adding them would be nice a little improvement to daily PHP developer experience.
> On Jun 23, 2021, at 10:52 AM, G. P. B. <george.banyard@gmail.com> wrote: > > All this to say that the burden of maintenance for such a specialized > function makes it very unsuitable to be in core.
I have frequently heard the justification of maintenance burden mentioned as an objection to adding specific features. And in many cases, it is easy to see why future maintenance burden would be a concern. However, it *seems* in this case that these functions are so trivial to implement that once written and documented they would likely never need to be touched again. But as I do not yet know the internals of PHP I obviously do not know that to be a fact. Honest question: Would you mind explaining the type of maintenance required for simple functions like this? What is likely to change in the future that would require maintenance? And would you mind giving a few or at least one example of a trivial function that did need to be maintained after it was written? Thank you in advance for taking the time and effort to answer. -Mike

Christoph Becker

5 years ago
On 23.06.2021 at 21:10, Mike Schinkel wrote:
> Replying to both Sara's and G.P.B.'s emails below: > >> On Jun 23, 2021, at 12:48 PM, Sara Golemon <pollita@php.net> wrote: >> >> Using some context, I would assume you mean this: >> >> function str_left(string $str, int $len): string { >> return substr($str, 0, $len); >> } >> >> function str_right(string $str, int $len): string { >> return substr($str, -$len); >> } >> >> If that's the case, then.... why? As you can see, the existing >> functionality available is trivial to write. >> <snip> >> Am I misunderstanding what these proposed functions should do, or am I >> underestimating the difficulty of typing a zero or negative sign on certain >> keyboards? > > I can't speak for Hamza, but one reason I can see for why — at least for str_right() — is that using a negative index might not occur to many people. Hell, I even forgot substr() worked that way until you mentioned it. > > But, since objective evidence is better than opinion, a non-trivial number of people have searched how to get the last 'n' characters from a string in PHP, found the answer, and then went to the effort to upvote it on StackOverflow. If the 90-9-1 rule holds, then that's about 6200 people who have been confused, searched and found the answer here: > > https://stackoverflow.com/questions/10542310/how-can-i-get-the-last-7-characters-of-a-php-string <https://stackoverflow.com/questions/10542310/how-can-i-get-the-last-7-characters-of-a-php-string>
substr() is about bytes, not characters. They all may have upvoted the wrong answer. The only correct answer has just 17 upvotes. Christoph

Rowan Collins

5 years ago
On 23/06/2021 22:28, Christoph M. Becker wrote:
> substr() is about bytes, not characters. They all may have upvoted the > wrong answer. The only correct answer has just 17 upvotes.
Just to out-pedant you, I'll point out that what most people would think of as a "character" is neither a byte nor a code point, but a grapheme, so I would say *none* of the answers on that page is correct. $string = 'Zoë'; // "Zoe\u{0308}" not "Zo\u{00EB}" var_dump(substr($string, -1)); var_dump(mb_substr($string, -1)); var_dump(grapheme_substr($string, -1)); string(1) "�" string(2) "̈" string(3) "ë" https://3v4l.org/IMoWQ Regards,
-- Rowan Tommins [IMSoP]

Guilliam Xavier

5 years ago
On Wed, Jun 23, 2021 at 11:54 PM Rowan Tommins <rowan.collins@gmail.com> wrote:
> On 23/06/2021 22:28, Christoph M. Becker wrote: > > substr() is about bytes, not characters. They all may have upvoted the > > wrong answer. The only correct answer has just 17 upvotes. > > > Just to out-pedant you, I'll point out that what most people would think > of as a "character" is neither a byte nor a code point, but a grapheme, > so I would say *none* of the answers on that page is correct. > > $string = 'Zoë'; // "Zoe\u{0308}" not "Zo\u{00EB}" > > var_dump(substr($string, -1)); > var_dump(mb_substr($string, -1)); > var_dump(grapheme_substr($string, -1)); > > string(1) "�" > string(2) "̈" > string(3) "ë" > > https://3v4l.org/IMoWQ >
I thought about the same during the night! Just to complete: there's also iconv_substr() (but with the same result as mb_substr()), and here are two links to compare: https://3v4l.org/kU9D5 vs https://3v4l.org/pAvB0 Regards,
-- Guilliam Xavier

Sara Golemon

5 years ago
On Wed, Jun 23, 2021 at 2:10 PM Mike Schinkel <mike@newclarity.net> wrote:
> I have frequently heard the justification of maintenance burden mentioned > as an objection to adding specific features. And in many cases, it is easy > to see why future maintenance burden would be a concern. > > However, it *seems* in this case that these functions are so trivial to > implement that once written and documented they would likely never need to > be touched again. But as I do not yet know the internals of PHP I obviously > do not know that to be a fact. > > Honest question: Would you mind explaining the type of maintenance > required for simple functions like this? What is likely to change in the > future that would require maintenance? And would you mind giving a few or > at least one example of a trivial function that did need to be maintained > after it was written? > >
Honest answer. I won't personally feel any pain from adding these functions. No more than I felt when str_contains() was added over my objections. Nobody maintaining PHP will feel significant burden from them. They'll sit in ext/standard/string.c doing their trivial work, opaque to the jit, and they'll get used or not. If cluttering the kitchen sink with one more unwashed utensil makes someone happy, then fine. I'm not going to vote for it though, because it belongs in composer/packagist land, not in core. I've listed the reasons for this in the str_contains() threads, feel free to reference those, they're still valid and correct. -Sara P.S. - I don't actually think the octet versus codepoint versus grapheme argument can be particularly persuasive given that our core string functions aren't encoding aware in the slightest. That ship has sailed. It is, however, another argument for doing this in userspace where the tradeoff is far more obvious, and dealing with alternative multibyte engines and/or polyfills is much more facile.

Unnamed Person

5 years ago
To George, et al, HI George,
> I really don't see the point of these functions.
These functions provide a clearer semantics for their usage. Substr, as Sara has mentioned, can be an alternative to these functions. Does it make clear that substr returns the either ends of a string? No, substr returns a part of a string, not ends. Although both mean similar, and substr can be used in absence of these functions, saying so is not linguisticly true! If these functions are added, one can make sense of what these functions actually do, without involving extra thought process. Furthermore, it will help code readers decode their purpose at the cognitive level, and that will provide with a faster understanding of the code. Therefore, Microsoft is using AI to design a clearer language to aid human minds understand quickly. I don't know how your mind functions, but allow me to explain my thought process. When I see substr, my mind says it is going to be a part of string from x offset to y offset. Then, I look at the offsets, I learn that it is either going to be a left end or a right end. If these functions are added to PHP, programmers will have a clear idea of what is going on there using a single thought. You are free to accuse me of mixing both psychology and computer science. HI Sara,
> you didn't explain what they're meant to actually do.
I thank you for pointing this out and also providing with the userland examples of these functions. As for the second function, I myself some time ago learnt that negative indexes are supported in substr. When I wrote this function for the first time, I used some other technique. As I have explained above that these functions are too common and useful, I don't find any big issue if these functions are added to core. IN VB, both mid and left/right functions exist. Hi Guilliam,
> I think that's more about "semantics" ("conveying intent to readers") than typing...
True, this is the main objective and motivation. Please, see the second paragraph that I dedicated to George. Hello Mike,
> str_right() would provide an obvious solution that would be easy to find in IDE autocomplete or...
I thank you for adding to the discussion. When I first time felt the need of str_right, I wrote this in a following way. ``` function right($str, $num) { return substr($str, strlen($str) - $num); }; `` Your opinion has strengthened my argument in three respects. First, these functions are often searched for and wanted in the community. Second, these functions will make the semantics clear. Third, these functions are too clear in their signatures and purpose, and one would hardly need to modify them. Nor, we need to add extra parameters and introduce new behaviors, like JSON indentation RFC. As for multibyte string functions, this is another domain. IF one wants to add mb_ these functions, it can also think of. Hi Christoph,
> substr() is about bytes, not characters.
Yes. Because PHP has MB string functions separately, implementation of these functions will be once for all. There will hardly be a need of touching these functions again. Hi Rowan, I thank you for providing with an other opinion. Here, I am only talking about the basic string functions. As for the MB functions, I am sure if these functions are added to core, they will also acquire their place in mb_* functions list. Because the time is approaching, what do you all suggest whether this request requires an RFC? I thank you all for providing me with your opinions. I wish this thread leads a positive consensus. Best Hamza Ahmad On 6/24/21, Sara Golemon <pollita@php.net> wrote:

Girgias

5 years ago
On Thu, 24 Jun 2021 at 07:20, Hamza Ahmad <office.hamzaahmad@gmail.com> wrote:
> HI George, > > > I really don't see the point of these functions. > > These functions provide a clearer semantics for their usage.
Are they though? The naming doesn't convey anything as pointed out by Kamil.
> Substr, > as Sara has mentioned, can be an alternative to these functions. Does > it make clear that substr returns the either ends of a string? No, > substr returns a part of a string, not ends. Although both mean > similar, and substr can be used in absence of these functions, saying > so is not linguisticly true! >
This is factually wrong, the first/last n characters of a string IS a substring of the original string. And by that logic left and right are actually linguistically incorrect due to languages being read Right to Left or Top to Bottom.
> If these functions are added, one can make sense of what these > functions actually do, without involving extra thought process. > Furthermore, it will help code readers decode their purpose at the > cognitive level, and that will provide with a faster understanding of > the code. Therefore, Microsoft is using AI to design a clearer > language to aid human minds understand quickly. I don't know how your > mind functions, but allow me to explain my thought process. When I see > substr, my mind says it is going to be a part of string from x offset > to y offset. Then, I look at the offsets, I learn that it is either > going to be a left end or a right end. If these functions are added to > PHP, programmers will have a clear idea of what is going on there > using a single thought. You are free to accuse me of mixing both > psychology and computer science. >
A language, be that spoken or programming, provides you with building blocks that you can combine to form larger constructs to express thoughts or a logical operation. Here you are basically asking to add a whole new set of half done constructions just because you didn't know a fundamental aspect of the PHP language, which is that string offsets can be negative, a fact that you can use broadly across the language. Now, why did you not know this is a more interesting question to solve, is it documentation? You never needed to do this before? etc. Moreover, the fact that only a very restricted number of programming languages, which are some of the earliest languages ever, implement those functions should tell you something about programming language design as a whole, which is that many people came to the conclusion that a variant of substring is a better abstraction than "left/right". I'll indulge you in my thought process which plainly is, "oh I'm extracting part of this string, oh this takes the first/last n bytes, fair enough", contrast this with how you'd need to perform str_contains() previously strpos($haystack, $needle) !== false "Okay I'm looking to find if a needle is in a haystack here, ... wait, am I because of the false? Ah no we're looking that it's just *somewhere* in the haystack" Which is fastly more complex and prone to logic errors if you need to touch this segment, a substring on the other hand, is always a substring.
> Because the time is approaching, what do you all suggest whether this > request requires an RFC? > > I thank you all for providing me with your opinions. I wish this > thread leads a positive consensus. >
Yes this requires an RFC, just by this thread alone you should realize this is controversial, and I'll personally vote against it because there is no advantage to have this in core at all. Regards, George P. Banyard

Mike Schinkel

5 years ago
> On Jun 24, 2021, at 8:04 AM, G. P. B. <george.banyard@gmail.com> wrote: > > Moreover, the fact that only a very restricted number of programming > languages, which are some of the earliest languages ever, implement those > functions should tell you something about programming language design > as a whole, which is that many people came to the conclusion that a variant > of substring is a better abstraction than "left/right".
It think the distinction is not so much that is earlier vs. later languages, but who the target market is for the languages. For languages that offer left() and right() function the average developer skill for developers proficient in those language tends to be lower than for languages that do not have those functions, compared on a absolute scale to the most highly-skilled professional developers, of course. Erlang has left() and right() string methods, and it is not an earlier language. R is not an early language and it has StrLeft() and StrRight() but R is a language targeting data scientists instead of hard core programmers. Visual Basic is not earlier, but it is based on early Basic. That said it has always targeted more line-of-business programmers than professional programmers. Excel, which is an end-users tool has LEFT() and RIGHT() functions. Wikipedia actual has a really nice comparison of languages on string handling: - https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(string_functions)#left <https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(string_functions)#left> - https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(string_functions)#right <https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(string_functions)#right> So a question to ask about PHP we could collectively answer is: Who is the target market for PHP? If we collectively want to forsake lower-skilled developers then no, it would not make sense to include str_left()/str_right() because few programming languages targeting more advanced developers do. OTOH if we do want to maintain approachability for lower-skilled developers and allow them easier success experiences then adding functions like str_left()/str_right() make a lot of sense. Maybe it would make sense to have the community identify and define who PHP's target user is, and then put that as a stake in the ground? If that were agreed and explicitly stated on PHP.net <http://php.net/> for reference, it sure could help stop a lot of bikeshedding and heated debates among people with different visions for the future of PHP. #justsaying ---- That said, many newer languages use the indexing operator to extract substrings of length 2 or more, which PHP does not. Given your comment about early languages are you amenable to adding a substring indexing syntax to PHP for strings and arrays? I quite like how Swift does it, but there are many others: - Swift: https://stackoverflow.com/a/39677331/102699 <https://stackoverflow.com/a/39677331/102699> - Go: https://www.dotnetperls.com/substring-go <https://www.dotnetperls.com/substring-go> - Python: https://runestone.academy/runestone/books/published/thinkcspy/Strings/IndexOperatorWorkingwiththeCharactersofaString.html <https://runestone.academy/runestone/books/published/thinkcspy/Strings/IndexOperatorWorkingwiththeCharactersofaString.html> - Ruby: https://stackoverflow.com/a/4528091/102699 <https://stackoverflow.com/a/4528091/102699> - F#: https://dotnetcodr.com/2017/02/18/creating-substrings-in-f/ <https://dotnetcodr.com/2017/02/18/creating-substrings-in-f/> - D: https://stackoverflow.com/a/20570677/102699 <https://stackoverflow.com/a/20570677/102699> - Mathematica: https://reference.wolfram.com/language/ref/StringTake.html <https://reference.wolfram.com/language/ref/StringTake.html> -Mike

Unnamed Person

5 years ago
To George
> substring of the original string. And by that logic left and right are > actually linguistically incorrect due to languages being read Right to Left > or Top to Bottom.
Thanks George for pointing out an important aspect regarding the choice of names. Will you consider a vote if there is a better name? I do admire your idea of respecting other languages. In 21st centuary, people are considering these facts. Recent developments, such as GitHub’s decision to rename master to main, is a famous example of these. Even Coq developers want to rename it just because it was supposedly associated with mail anatomy . Refference: https://developer-tech.com/news/2021/jun/15/programming-language-coq-change-name-obvious-reasons/
> only a very restricted number of programming > languages, which are some of the earliest languages ever, implement those > functions should tell you something about programming language design > as a whole,
Another member on the list, namely Mike, has added to the discussion and I second his opinion.
> Yes this requires an RFC, just by this thread alone you should realize > this is controversial, and I'll personally vote against it because there is > no advantage to have this in core at all.
Sure, I would love to come up with an RFC. This thread has provided me with enough content to build my argument. I am thankful to you for razing many great points, such as descriptive naming. As for voting rights, it is yours, sir,, and no one is stealing this from you. Though you are against this proposal, what if you reconsider and revisit your idea? Just because Sara and You and also my friends at php.earth are against it, it does not mean that people are not supporting it. I am following it on externals, some people down-voted this thread and some up-voted it. Currently, it is in positive number. I have referred to it just because people do follow our discussions and have mixed opinions regarding this. Best

Unnamed Person

5 years ago
> #justsaying
Mike, most of the developers in PHP have their background from web development, and they need easier solutions to their problems. As for your suggestion of including all suggested names in the RFC, I shall do this, too! Like others, I do have a dream for PHP that it may become an advanced language. Still, I feel like that we count everyone that uses this language. Well, I am going for an RFC. Best.

Girgias

5 years ago
On Fri, 25 Jun 2021 at 08:26, Hamza Ahmad <office.hamzaahmad@gmail.com> wrote:
> To George > > > substring of the original string. And by that logic left and right are > > actually linguistically incorrect due to languages being read Right to > Left > > or Top to Bottom. > > Thanks George for pointing out an important aspect regarding the > choice of names. Will you consider a vote if there is a better name? >
No. Best regards, George P. Banyard

Guilliam Xavier

5 years ago
On Thu, Jun 24, 2021 at 12:51 AM Sara Golemon <pollita@php.net> wrote:
> > [...] I'm > not going to vote for it though, because it belongs in composer/packagist > land, not in core. I've listed the reasons for this in the str_contains() > threads, feel free to reference those, they're still valid and correct. >
Sorry I can't find your past message (searched for each of your first name, last name, username) :/ Anyway, I think you always get the same retort, "if it isn't in core it won't be used" basically? PS: I forgot in my previous reply: thank you for writing the polyfills clear =) Regards,
-- Guilliam Xavier

Kamil Tekiela

5 years ago
I am against adding these functions, but for different reasons than Sara and George. If we add str_left and str_right then there should be a corresponding variant in mbstring. The byte-string functions are rarely useful. Adding these functions to mbstring unnecessarily complicates the extension for little to no gain. Another point is that if we decide to add them, then we will bikeshed forever in an unresolvable manner about the name. Should it be called str_left or strleft? Current functions don't have a naming convention, so using either variant will be wrong. Personally, I find substr to be more clear about the intent. I know that I am asking for a part of the string. Whereas str_left doesn't convey an action immediately. Without knowing its purpose I wouldn't know if it will pad the string from the left, strip characters from left, or take the leftmost part of the string. Don't take it the wrong way, but I think it's a waste of time to implement a function that doesn't even need a polyfill in the userland. Regards, Kamil

Guilliam Xavier

5 years ago
On Thu, Jun 24, 2021 at 1:17 PM Kamil Tekiela <tekiela246@gmail.com> wrote:
> I am against adding these functions, but for different reasons than Sara > and George. > If we add str_left and str_right then there should be a corresponding > variant in mbstring. The byte-string functions are rarely useful. Adding > these functions to mbstring unnecessarily complicates the extension for > little to no gain. >
So you seem to relate to Christoph's (and Rowan's) point.
> Another point is that if we decide to add them, then we will bikeshed > forever in an unresolvable manner about the name. Should it be called > str_left or strleft? Current functions don't have a naming convention, so > using either variant will be wrong. >
To be fair, most "strxxx" functions were historically more-or-less copied from C; most recent additions have been "str_xxx".
> Personally, I find substr to be more clear about the intent. I know that I > am asking for a part of the string. Whereas str_left doesn't convey an > action immediately. Without knowing its purpose I wouldn't know if it will > pad the string from the left, strip characters from left, or take the > leftmost part of the string. >
True, I can also imagine bikeshed like "str_leftmost", "str_start", "str_first[_n]" (and same for rightmost/end/last)...
> Don't take it the wrong way, but I think it's a waste of time to implement > a function that doesn't even need a polyfill in the userland. > > Regards, > Kamil >
-- Guilliam Xavier

Unnamed Person

5 years ago
HI Kamil, Thanks for the opinions. I have two questions: 1. Though it's true that naming choice is something to discuss about, is it really a big issue that can prevent from these functions to be introduced? We can ask both developers and user community about the name choice. 2. Since my basic goal is to have the functionality rather names, I would love to see more descriptive and concise names. What name do you suggest instead of these two? Because left and right are used in both MySQL and VB, a large number of people is already familiar with these names. However, I don't prefer this scheme because it can go against PHP's naming schemes. I know some of the string functions don't follow str_* and s* naming scheme. We can let democracy decide the right name. If PHP later has a string object, dev(s) can make left and right as its methods respectively. Best Hamza Ahmad On 6/24/21, Kamil Tekiela <tekiela246@gmail.com> wrote:

Andreas Leathley

5 years ago
On 24.06.21 13:17, Kamil Tekiela wrote:
> I am against adding these functions, but for different reasons than Sara > and George. > If we add str_left and str_right then there should be a corresponding > variant in mbstring. The byte-string functions are rarely useful. Adding > these functions to mbstring unnecessarily complicates the extension for > little to no gain. > Another point is that if we decide to add them, then we will bikeshed > forever in an unresolvable manner about the name. Should it be called > str_left or strleft? Current functions don't have a naming convention, so > using either variant will be wrong. > Personally, I find substr to be more clear about the intent. I know that I > am asking for a part of the string. Whereas str_left doesn't convey an > action immediately. Without knowing its purpose I wouldn't know if it will > pad the string from the left, strip characters from left, or take the > leftmost part of the string. > Don't take it the wrong way, but I think it's a waste of time to implement > a function that doesn't even need a polyfill in the userland.
str_left / str_right also seems very unclear to me in terms of the name. But I don't think naming new string functions in general should be difficult - the recent string additions have all started with str_ (like str_contains, str_starts_with) which seems more readable than any of the non-underscore functions. I do think the intended functions can make sense, just because I find substr to be a bit obnoxious - with a necessary offset and an optional length it rarely is obvious to me at a glance what the intention is, as you can do so many different things with it, because offset and length can be positive or negative, and then very different things happen. These new functions are quite similar to str_contains or str_starts_with for me, in that you don't need them, but it makes code so much more readable. str_left_part(string $string, int $length) would make it clear the left part of the string is returned, and it could throw an exception if $length is negative. With substr you might accidentally give it a negative length, or would need to check if a length is positive or negative (if it is in a variable) to know what is happening. str_right_part(string $string, int $length) would make it clear the right part of the string is returned. And if you compare substr usage to these two functions, it might come through how different in arguments & readability it is: substr($string, -3); str_right_part($string, 3); substr($string, 0, 3); str_left_part($string, 3); substr($string, -6, 3); str_left_part(str_right_part($string, 6), 3); If you use substr all the time you might be used to it, but to me I have to stop and think what is happening each time more than would be necessary with dedicated functions. A function like str_contains definitely had a bigger impact than something like str_left_part would have, but it would still make a difference. (By the way, str_left_part/str_right_part is just what came to mind, could be anything as long as it conveys what it is doing clearly enough, which probably always needs two words, not just one)

Unnamed Person

5 years ago
> I can also imagine bikeshed...
This is what can be discussed apart from whether these function come to PHP. I am waiting for the other voices; there is surely someone that can come up with a more creative name, a name that is short yet descriptive.
> str_left_part/str_right_part is just what came to mind,
I thank you, Andreas, for suggesting new names. You are right that substr can give surprising results. Str_starts_with and ends_with return bool, not strings. So, we do have need of these functions. Best