Introduce str_left/right In 8.1

3 years ago by Hamza Ahmad — view source

unread

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:

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.
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.
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.
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

3 years ago by G. P. B. — view source

unread

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:

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.

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.

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.

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

--

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

3 years ago by Sara Golemon — view source

unread

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

3 years ago by Guilliam Xavier — view source

unread

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

3 years ago by Mike Schinkel — view source

unread

Replying to both Sara's and G.P.B.'s emails below:

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.

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

3 years ago by Christoph M. Becker — view source

unread

Replying to both Sara's and G.P.B.'s emails below:

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

3 years ago by Rowan Tommins — view source

unread

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 = 'Zoë'; // "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) "ë"

https://3v4l.org/IMoWQ

Regards,

--
Rowan Tommins
[IMSoP]

3 years ago by Guilliam Xavier — view source

unread

On Wed, Jun 23, 2021 at 11:54 PM Rowan Tommins rowan.collins@gmail.com
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 = 'Zoë'; // "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) "ë"

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

3 years ago by Sara Golemon — view source

unread

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.

3 years ago by Hamza Ahmad — view source

unread

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



> 
>
>> 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.

3 years ago by G. P. B. — view source

unread

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

3 years ago by Mike Schinkel — view source

unread

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:

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:

-Mike

3 years ago by Hamza Ahmad — view source

unread

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

3 years ago by Hamza Ahmad — view source

unread

#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.

3 years ago by G. P. B. — view source

unread

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

3 years ago by Guilliam Xavier — view source

unread

[...] 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

3 years ago by Kamil Tekiela — view source

unread

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

3 years ago by Guilliam Xavier — view source

unread

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

3 years ago by Hamza Ahmad — view source

unread

HI Kamil,

Thanks for the opinions. I have two questions:

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.
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

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

3 years ago by Andreas Leathley — view source

unread

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)

3 years ago by Hamza Ahmad — view source

unread

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