Hello,
I would like to submit an RFC for adding a str_begins and str_ends
function, in relation to https://bugs.php.net/bug.php?id=67035 and
https://bugs.php.net/bug.php?id=50434. I've added those functions on my
local PHP copy. I would like to make an RFC and a PR for adding it to
the core PHP copy.
Thanks,
Will
Questions:
Have you talked with this list about the terms of you suggestions?
(like str_begins, str_starts, strstarts, strbegins, str_ends,
strends...)
Is yes, sorry, I do not received this topic before.
There some valid performance advantage over strpos()
?
And about the "market" for this new function?
I mean, about users really need a new function like it on core.
And about the case sensitiblity?
Should have some function like stribegins() or will be an argument?
In general, I like this implementation, but I like to know about you
in this questions.
I don't know the policy about implements new functions on "str namespace".
Thanks!
2016-07-26 15:41 GMT-03:00 will@wkhudgins.info:
Hello,
I would like to submit an RFC for adding a str_begins and str_ends function,
in relation to https://bugs.php.net/bug.php?id=67035 and
https://bugs.php.net/bug.php?id=50434. I've added those functions on my
local PHP copy. I would like to make an RFC and a PR for adding it to the
core PHP copy.Thanks,
Will
--
--
David Rodrigues
Thanks for replying David.
Thanks for the questions, its good to elaborate on things some. I'll
address each question here:
-
No, I guess this is my first time reaching out to the community. I
had gone with str_begins and str_ends because it fit some of the current
naming approaches. I could see an argument for strstarts/strends,
strbegins/strends, or startsWith/endsWith. I'm flexible with the exact
naming. -
I don't think performance-wise it would be a big improvement over
using strpos, preg_match, or substr. However, I think it might be an
improvement readability-wise. Right now people either use somewhat
confusing code, like strpos or substr, or they implement their own
user-defined str_starts function. I think the benefit in terms of
readability and usability justifies the addition of two new functions to
the namespace. -
This functionality is doable with the current implementation.
However, part of the goal of languages or tools is to make it easy to do
common, routine tasks. Python, Java, Ruby, C# and JavaScript all provide
this functionality. So I am sure people would find it useful in PHP. -
Right now, the way I have it implemented, it is case-sensitive. If
people wanted, it could be implemented to take an optional boolean
parameter called case_sensitive which defaults to true. I could make
that change pretty easily, if I did that the function headers would be:
boolean str_starts (string $str , str $search_value [, bool
$case_sensitive = true ] )
boolean str_ends (string $str , str $search_value [, bool
$case_sensitive = true ] )
I like the idea of doing that instead of having separate,
case-insensitive, functions because it helps keep the name space less
cluttered.
I hope this has provided some helpful information. Please get back with
me with your thoughts.
Thanks,
Will
Questions:
Have you talked with this list about the terms of you suggestions?
(like str_begins, str_starts, strstarts, strbegins, str_ends,
strends...)
Is yes, sorry, I do not received this topic before.
There some valid performance advantage over
strpos()
?
And about the "market" for this new function?
I mean, about users really need a new function like it on core.
And about the case sensitiblity?
Should have some function like stribegins() or will be an argument?In general, I like this implementation, but I like to know about you
in this questions.
I don't know the policy about implements new functions on "str
namespace".Thanks!
2016-07-26 15:41 GMT-03:00 will@wkhudgins.info:
Hello,
I would like to submit an RFC for adding a str_begins and str_ends
function,
in relation to https://bugs.php.net/bug.php?id=67035 and
https://bugs.php.net/bug.php?id=50434. I've added those functions on
my
local PHP copy. I would like to make an RFC and a PR for adding it to
the
core PHP copy.Thanks,
Will
Will,
Now that we have generalized support for negative string offsets you can
now just do:
$string = "/foo/bar/bat/";
if ($string[0] === "/") { // fully-qualified path }
if ($string[-1] === "/") { // trailing "/" }
This avoids the overhead of a function call, arguably is as expressive, and
a lot more functional (e.g. offset -2).
- Davey
Thanks for replying David.
Thanks for the questions, its good to elaborate on things some. I'll
address each question here:
No, I guess this is my first time reaching out to the community. I had
gone with str_begins and str_ends because it fit some of the current naming
approaches. I could see an argument for strstarts/strends,
strbegins/strends, or startsWith/endsWith. I'm flexible with the exact
naming.I don't think performance-wise it would be a big improvement over using
strpos, preg_match, or substr. However, I think it might be an improvement
readability-wise. Right now people either use somewhat confusing code, like
strpos or substr, or they implement their own user-defined str_starts
function. I think the benefit in terms of readability and usability
justifies the addition of two new functions to the namespace.This functionality is doable with the current implementation. However,
part of the goal of languages or tools is to make it easy to do common,
routine tasks. Python, Java, Ruby, C# and JavaScript all provide this
functionality. So I am sure people would find it useful in PHP.Right now, the way I have it implemented, it is case-sensitive. If
people wanted, it could be implemented to take an optional boolean
parameter called case_sensitive which defaults to true. I could make that
change pretty easily, if I did that the function headers would be:boolean str_starts (string $str , str $search_value [, bool
$case_sensitive = true ] )
boolean str_ends (string $str , str $search_value [, bool $case_sensitive
= true ] )I like the idea of doing that instead of having separate,
case-insensitive, functions because it helps keep the name space less
cluttered.I hope this has provided some helpful information. Please get back with me
with your thoughts.Thanks,
WillQuestions:
Have you talked with this list about the terms of you suggestions?
(like str_begins, str_starts, strstarts, strbegins, str_ends,
strends...)
Is yes, sorry, I do not received this topic before.
There some valid performance advantage over
strpos()
?
And about the "market" for this new function?
I mean, about users really need a new function like it on core.
And about the case sensitiblity?
Should have some function like stribegins() or will be an argument?In general, I like this implementation, but I like to know about you
in this questions.
I don't know the policy about implements new functions on "str namespace".Thanks!
2016-07-26 15:41 GMT-03:00 will@wkhudgins.info:
Hello,
I would like to submit an RFC for adding a str_begins and str_ends
function,
in relation to https://bugs.php.net/bug.php?id=67035 and
https://bugs.php.net/bug.php?id=50434. I've added those functions on my
local PHP copy. I would like to make an RFC and a PR for adding it to the
core PHP copy.Thanks,
Will
Davey,
Thanks for joining the conversation! That code snippet is very elegant,
and it is a superb way of checking if a string starts with or ends with
a specific character. However, it does not check if a string starts with
or ends with a specific string, containing multiple characters.
True str_begins and str_ends would do check if a string begins or ends
with a string of n characters.
Regards,
-Will
Will,
Now that we have generalized support for negative string offsets you
can now just do:$string = "/foo/bar/bat/";
if ($string[0] === "/") { // fully-qualified path }
if ($string[-1] === "/") { // trailing "/" }This avoids the overhead of a function call, arguably is as
expressive, and a lot more functional (e.g. offset -2).
- Davey
Thanks for replying David.
Thanks for the questions, its good to elaborate on things some. I'll
address each question here:
No, I guess this is my first time reaching out to the community.
I had gone with str_begins and str_ends because it fit some of the
current naming approaches. I could see an argument for
strstarts/strends, strbegins/strends, or startsWith/endsWith. I'm
flexible with the exact naming.I don't think performance-wise it would be a big improvement over
using strpos, preg_match, or substr. However, I think it might be an
improvement readability-wise. Right now people either use somewhat
confusing code, like strpos or substr, or they implement their own
user-defined str_starts function. I think the benefit in terms of
readability and usability justifies the addition of two new
functions to the namespace.This functionality is doable with the current implementation.
However, part of the goal of languages or tools is to make it easy
to do common, routine tasks. Python, Java, Ruby, C# and JavaScript
all provide this functionality. So I am sure people would find it
useful in PHP.Right now, the way I have it implemented, it is case-sensitive.
If people wanted, it could be implemented to take an optional
boolean parameter called case_sensitive which defaults to true. I
could make that change pretty easily, if I did that the function
headers would be:boolean str_starts (string $str , str $search_value [, bool
$case_sensitive = true ] )
boolean str_ends (string $str , str $search_value [, bool
$case_sensitive = true ] )I like the idea of doing that instead of having separate,
case-insensitive, functions because it helps keep the name space
less cluttered.I hope this has provided some helpful information. Please get back
with me with your thoughts.Thanks,
WillQuestions:
Have you talked with this list about the terms of you suggestions?
(like str_begins, str_starts, strstarts, strbegins, str_ends,
strends...)
Is yes, sorry, I do not received this topic before.
There some valid performance advantage over
strpos()
?
And about the "market" for this new function?
I mean, about users really need a new function like it on core.
And about the case sensitiblity?
Should have some function like stribegins() or will be an argument?In general, I like this implementation, but I like to know about you
in this questions.
I don't know the policy about implements new functions on "str
namespace".Thanks!
2016-07-26 15:41 GMT-03:00 will@wkhudgins.info:
Hello,I would like to submit an RFC for adding a str_begins and str_ends
function,
in relation to https://bugs.php.net/bug.php?id=67035 and
https://bugs.php.net/bug.php?id=50434. I've added those functions on
my
local PHP copy. I would like to make an RFC and a PR for adding it
to the
core PHP copy.Thanks,
Will
Ah, I missed that. If we had ranges (e.g. $string[0..4] or $string[-1..4])
that'd work, but we don't.
Now I see some value in the function, though still perhaps not enough to
justify above and beyond strpos etc.
Davey,
Thanks for joining the conversation! That code snippet is very elegant,
and it is a superb way of checking if a string starts with or ends with a
specific character. However, it does not check if a string starts with or
ends with a specific string, containing multiple characters.True str_begins and str_ends would do check if a string begins or ends
with a string of n characters.Regards,
-Will
Will,
Now that we have generalized support for negative string offsets you
can now just do:$string = "/foo/bar/bat/";
if ($string[0] === "/") { // fully-qualified path }
if ($string[-1] === "/") { // trailing "/" }This avoids the overhead of a function call, arguably is as
expressive, and a lot more functional (e.g. offset -2).
- Davey
Thanks for replying David.
Thanks for the questions, its good to elaborate on things some. I'll
address each question here:
No, I guess this is my first time reaching out to the community.
I had gone with str_begins and str_ends because it fit some of the
current naming approaches. I could see an argument for
strstarts/strends, strbegins/strends, or startsWith/endsWith. I'm
flexible with the exact naming.I don't think performance-wise it would be a big improvement over
using strpos, preg_match, or substr. However, I think it might be an
improvement readability-wise. Right now people either use somewhat
confusing code, like strpos or substr, or they implement their own
user-defined str_starts function. I think the benefit in terms of
readability and usability justifies the addition of two new
functions to the namespace.This functionality is doable with the current implementation.
However, part of the goal of languages or tools is to make it easy
to do common, routine tasks. Python, Java, Ruby, C# and JavaScript
all provide this functionality. So I am sure people would find it
useful in PHP.Right now, the way I have it implemented, it is case-sensitive.
If people wanted, it could be implemented to take an optional
boolean parameter called case_sensitive which defaults to true. I
could make that change pretty easily, if I did that the function
headers would be:boolean str_starts (string $str , str $search_value [, bool
$case_sensitive = true ] )
boolean str_ends (string $str , str $search_value [, bool
$case_sensitive = true ] )I like the idea of doing that instead of having separate,
case-insensitive, functions because it helps keep the name space
less cluttered.I hope this has provided some helpful information. Please get back
with me with your thoughts.Thanks,
WillQuestions:
Have you talked with this list about the terms of you suggestions?
(like str_begins, str_starts, strstarts, strbegins, str_ends,
strends...)
Is yes, sorry, I do not received this topic before.
There some valid performance advantage over
strpos()
?
And about the "market" for this new function?
I mean, about users really need a new function like it on core.
And about the case sensitiblity?
Should have some function like stribegins() or will be an argument?In general, I like this implementation, but I like to know about you
in this questions.
I don't know the policy about implements new functions on "str
namespace".Thanks!
2016-07-26 15:41 GMT-03:00 will@wkhudgins.info:
Hello,I would like to submit an RFC for adding a str_begins and str_ends
function,
in relation to https://bugs.php.net/bug.php?id=67035 and
https://bugs.php.net/bug.php?id=50434. I've added those functions on
my
local PHP copy. I would like to make an RFC and a PR for adding it
to the
core PHP copy.Thanks,
Will
Ah, I missed that. If we had ranges (e.g. $string[0..4] or $string[-1..4])
that'd work, but we don't.
However, that still would require something like
$str[0..mb_strlen($needle)-1] == $needle
Now I see some value in the function, though still perhaps not enough to
justify above and beyond strpos etc.
One advantage of the new functions over userland implementations would
be efficiency. A strpos()
would still require to search the whole
string if the $needle is not found. substr()
and string slices would
require a copy unless that would be optimized, if a general optimization
is possible at all.
Not sure, if I like to see yet two more string functions in the global
namespace, though.
--
Christoph M. Becker
2016-07-27 12:24 GMT+02:00 Christoph Becker cmbecker69@gmx.de:
Ah, I missed that. If we had ranges (e.g. $string[0..4] or
$string[-1..4])
that'd work, but we don't.However, that still would require something like
$str[0..mb_strlen($needle)-1] == $needle
I've been working on range operator some time ago and had problem with
double-dot ".." as an operator because of conflict with concat operator.
0..5 could be 0. . 5, or 0 . .5 white spaces are problem here,
unfortunately dot is concat operator and decimal separator.
Now I see some value in the function, though still perhaps not enough to
justify above and beyond strpos etc.One advantage of the new functions over userland implementations would
be efficiency. Astrpos()
would still require to search the whole
string if the $needle is not found.substr()
and string slices would
require a copy unless that would be optimized, if a general optimization
is possible at all.Not sure, if I like to see yet two more string functions in the global
namespace, though.--
Christoph M. Becker--
--
pozdrawiam
Michał Brzuchalski
On 27.07.2016 at 13:53, Michał Brzuchalski:
2016-07-27 12:24 GMT+02:00 Christoph Becker cmbecker69@gmx.de:
However, that still would require something like
$str[0..mb_strlen($needle)-1] == $needle
I've been working on range operator some time ago and had problem with
double-dot ".." as an operator because of conflict with concat operator.
0..5 could be 0. . 5, or 0 . .5 white spaces are problem here,
unfortunately dot is concat operator and decimal separator.
Well, there's a similar issue with - -$n
vs. --$n
anyway, but of
course we could use something else than ..
(:
comes to mind; not
sure if that would work).
--
Christoph M. Becker
Hello,
I would like to submit an RFC for adding a str_begins and str_ends
function, in relation to https://bugs.php.net/bug.php?id=67035 and
https://bugs.php.net/bug.php?id=50434. I've added those functions on my
local PHP copy. I would like to make an RFC and a PR for adding it to the
core PHP copy.Thanks,
Will
--
hi,
I've just granted you rfc karma on the wiki.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu