Attached you'll find a patch against PHP_5_3 that implements two new
string functions:
str_startswith(haystack, needle [, case_sensitivity])
checks if haystack starts with needle. The check is performed
case-insensitively, but this can be overridden by passing TRUE as the
value for the third parameter. The second function
str_endswith(haystack, needle [, case_sensitivity])
checks if haystack ends with needle and has the same semantics
regarding case-sensitivity.
I admit that both functions can be easily implemented in userland with
already existing functions. At the same time I like them because they
make the common tasks of prefix and suffix checks easy and convenient.
I won't mind if you guys don't like the idea (I did it mainly for
personal entertainment and learning about PHP internals), but if you
are interested I'll happily provide a patch for HEAD, too. Also since
this is my first foray into PHP internals, comments and corrections
are more then appreciated.
Martin
Hi Martin,
first of all, thanks for you work! A few comments below.
Am Samstag, den 19.07.2008, 14:55 +0200 schrieb Martin Jansen:
Attached you'll find a patch against PHP_5_3 that implements two new
string functions:str_startswith(haystack, needle [, case_sensitivity])
That's in my opinion too easy to solve with strpos($haystack, $needle)
=== 0.
checks if haystack starts with needle. The check is performed
case-insensitively, but this can be overridden by passingTRUEas the
value for the third parameter. The second functionstr_endswith(haystack, needle [, case_sensitivity])
[...]
Suffix checking is indeed a bit harder. But I'm not sure if we should
introduce a function for every special case. Suffix verification often
is about verifying file extensions. That could be easily solved with
pathinfo() (and to make that easier, it would be more helpful to allow
the engine to directly access returned arrays like
pathinfo($file)['extension']). The other thing I would love to see is
something I really love in Ruby: you have various ways to work with
substrings[1]. For example you can do "foobar"[-3,3] == "bar" to check
the suffix. That's in my opinion much easier and flexible.
So -1 from me for the new string functions, but +1 for niftier variants
to work with offsets.
[1] http://pleac.sourceforge.net/pleac_ruby/strings.html
cu, Lars
For the start of the string:
substr($haystack,0,strlen($needle)) == $needle
And for the end of the string:
substr($haystack,-strlen($needle)) == $needle
For case-insensitivity, just strtolower both.
Writing built-in functions for something that can be done with trivial
one-liners isn't something we typically do.
-Rasmus
Lars Strojny wrote:
Hi Martin,
first of all, thanks for you work! A few comments below.
Am Samstag, den 19.07.2008, 14:55 +0200 schrieb Martin Jansen:
Attached you'll find a patch against PHP_5_3 that implements two new
string functions:str_startswith(haystack, needle [, case_sensitivity])
That's in my opinion too easy to solve with strpos($haystack, $needle)
=== 0.checks if haystack starts with needle. The check is performed
case-insensitively, but this can be overridden by passingTRUEas the
value for the third parameter. The second functionstr_endswith(haystack, needle [, case_sensitivity])
[...]Suffix checking is indeed a bit harder. But I'm not sure if we should
introduce a function for every special case. Suffix verification often
is about verifying file extensions. That could be easily solved with
pathinfo()(and to make that easier, it would be more helpful to allow
the engine to directly access returned arrays like
pathinfo($file)['extension']). The other thing I would love to see is
something I really love in Ruby: you have various ways to work with
substrings[1]. For example you can do "foobar"[-3,3] == "bar" to check
the suffix. That's in my opinion much easier and flexible.So -1 from me for the new string functions, but +1 for niftier variants
to work with offsets.[1] http://pleac.sourceforge.net/pleac_ruby/strings.html
cu, Lars
Hi,
Actually starts with and ends with is a very common case. I see your
concerns, but I can see instantly quite a lot of places in my code where I'd
use those. And I bet it'll be faster too.
Many of the string functions can be replicated with one-liners using other
string functions, same for array functions. I still think a very common case
should be addressed natively.
Regards,
Stan Vassilev
For the start of the string:
substr($haystack,0,strlen($needle)) == $needle
And for the end of the string:
substr($haystack,-strlen($needle)) == $needle
For case-insensitivity, just strtolower both.
Writing built-in functions for something that can be done with trivial
one-liners isn't something we typically do.-Rasmus
Lars Strojny wrote:
Hi Martin,
first of all, thanks for you work! A few comments below.
Am Samstag, den 19.07.2008, 14:55 +0200 schrieb Martin Jansen:
Attached you'll find a patch against PHP_5_3 that implements two new
string functions:str_startswith(haystack, needle [, case_sensitivity])
That's in my opinion too easy to solve with strpos($haystack, $needle)
=== 0.checks if haystack starts with needle. The check is performed
case-insensitively, but this can be overridden by passingTRUEas the
value for the third parameter. The second functionstr_endswith(haystack, needle [, case_sensitivity])
[...]Suffix checking is indeed a bit harder. But I'm not sure if we should
introduce a function for every special case. Suffix verification often
is about verifying file extensions. That could be easily solved with
pathinfo()(and to make that easier, it would be more helpful to allow
the engine to directly access returned arrays like
pathinfo($file)['extension']). The other thing I would love to see is
something I really love in Ruby: you have various ways to work with
substrings[1]. For example you can do "foobar"[-3,3] == "bar" to check
the suffix. That's in my opinion much easier and flexible.So -1 from me for the new string functions, but +1 for niftier variants
to work with offsets.[1] http://pleac.sourceforge.net/pleac_ruby/strings.html
cu, Lars
I agree that many existing functions can be implemented with a
combination of others, but in this case it is really just one call. The
strlen() call is almost free, and in many cases you wouldn't even use
it. If you are looking for .php files, for example:
if(str_endswith($path,'.php'))
vs.
if(substr($path,-4)=='.php'))
I just don't see that this is solving any real painpoint.
-Rasmus
Stan Vassilev | FM wrote:
Hi,
Actually starts with and ends with is a very common case. I see your
concerns, but I can see instantly quite a lot of places in my code where
I'd use those. And I bet it'll be faster too.Many of the string functions can be replicated with one-liners using
other string functions, same for array functions. I still think a very
common case should be addressed natively.Regards,
Stan VassilevFor the start of the string:
substr($haystack,0,strlen($needle)) == $needle
And for the end of the string:
substr($haystack,-strlen($needle)) == $needle
For case-insensitivity, just strtolower both.
Writing built-in functions for something that can be done with trivial
one-liners isn't something we typically do.-Rasmus
Lars Strojny wrote:
Hi Martin,
first of all, thanks for you work! A few comments below.
Am Samstag, den 19.07.2008, 14:55 +0200 schrieb Martin Jansen:
Attached you'll find a patch against PHP_5_3 that implements two new
string functions:str_startswith(haystack, needle [, case_sensitivity])
That's in my opinion too easy to solve with strpos($haystack, $needle)
=== 0.checks if haystack starts with needle. The check is performed
case-insensitively, but this can be overridden by passingTRUEas the
value for the third parameter. The second functionstr_endswith(haystack, needle [, case_sensitivity])
[...]Suffix checking is indeed a bit harder. But I'm not sure if we should
introduce a function for every special case. Suffix verification often
is about verifying file extensions. That could be easily solved with
pathinfo()(and to make that easier, it would be more helpful to allow
the engine to directly access returned arrays like
pathinfo($file)['extension']). The other thing I would love to see is
something I really love in Ruby: you have various ways to work with
substrings[1]. For example you can do "foobar"[-3,3] == "bar" to check
the suffix. That's in my opinion much easier and flexible.So -1 from me for the new string functions, but +1 for niftier variants
to work with offsets.[1] http://pleac.sourceforge.net/pleac_ruby/strings.html
cu, Lars
Hi,
ucfirst() isn't solving a pain point either. But we use it all the time (I
do at least).
I'm particularly for begins/endswith() function as I do this all over my
code and I'd appreciate the simplification and free extra performance.
Regards,
Stan Vassilev
I agree that many existing functions can be implemented with a combination
of others, but in this case it is really just one call. Thestrlen()call
is almost free, and in many cases you wouldn't even use it. If you are
looking for .php files, for example:if(str_endswith($path,'.php'))
vs.
if(substr($path,-4)=='.php'))
I just don't see that this is solving any real painpoint.
-Rasmus
Stan Vassilev | FM wrote:
Hi,
Actually starts with and ends with is a very common case. I see your
concerns, but I can see instantly quite a lot of places in my code where
I'd use those. And I bet it'll be faster too.Many of the string functions can be replicated with one-liners using
other string functions, same for array functions. I still think a very
common case should be addressed natively.Regards,
Stan VassilevFor the start of the string:
substr($haystack,0,strlen($needle)) == $needle
And for the end of the string:
substr($haystack,-strlen($needle)) == $needle
For case-insensitivity, just strtolower both.
Writing built-in functions for something that can be done with trivial
one-liners isn't something we typically do.-Rasmus
Lars Strojny wrote:
Hi Martin,
first of all, thanks for you work! A few comments below.
Am Samstag, den 19.07.2008, 14:55 +0200 schrieb Martin Jansen:
Attached you'll find a patch against PHP_5_3 that implements two new
string functions:str_startswith(haystack, needle [, case_sensitivity])
That's in my opinion too easy to solve with strpos($haystack, $needle)
=== 0.checks if haystack starts with needle. The check is performed
case-insensitively, but this can be overridden by passingTRUEas the
value for the third parameter. The second functionstr_endswith(haystack, needle [, case_sensitivity])
[...]Suffix checking is indeed a bit harder. But I'm not sure if we should
introduce a function for every special case. Suffix verification often
is about verifying file extensions. That could be easily solved with
pathinfo()(and to make that easier, it would be more helpful to allow
the engine to directly access returned arrays like
pathinfo($file)['extension']). The other thing I would love to see is
something I really love in Ruby: you have various ways to work with
substrings[1]. For example you can do "foobar"[-3,3] == "bar" to check
the suffix. That's in my opinion much easier and flexible.So -1 from me for the new string functions, but +1 for niftier variants
to work with offsets.[1] http://pleac.sourceforge.net/pleac_ruby/strings.html
cu, Lars
Stan Vassilev | FM wrote:
I'm particularly for begins/endswith() function as I do this all over my
code and I'd appreciate the simplification and free extra performance.
I really don't mean to be rude here, but shorter and less typing !==
performance gain. The PHP string functions are very fast. And if you
are looking to improve your applications performance by using different
string functions, you are likely looking in the wrong place.
--
Brian Moon
Senior Web Engineer
When you care enough to spend the very least.
http://dealnews.com/
Brian Moon wrote:
Stan Vassilev | FM wrote:
I'm particularly for begins/endswith() function as I do this all over my
code and I'd appreciate the simplification and free extra performance.I really don't mean to be rude here, but shorter and less typing !==
performance gain. The PHP string functions are very fast. And if you are
looking to improve your applications performance by using different
string functions, you are likely looking in the wrong place.
It also isn't any shorter:
if(str_endswith($path,'.php'))
vs.
if(substr($path,-4)=='.php')
And there would be no performance gain since it can be done in a single
call now and the code would do pretty much exactly what substr does.
-Rasmus
Hi!
It also isn't any shorter:
if(str_endswith($path,'.php'))
vs.
if(substr($path,-4)=='.php')
Doesn't substr allocate new string for ".php"? Then endswith can have
one advantage of not requiring any new allocations. Not sure it's enough
to add it, but a point here to consider.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
W liście Rasmus Lerdorf z dnia poniedziałek, 21 lipca 2008:
It also isn't any shorter:
if(str_endswith($path,'.php'))
vs.
if(substr($path,-4)=='.php')
Only if comparing to a static string, but not for this case:
if (substr($path, -strlen($extension)) == $extension)
Readability would also increase.
--
Paweł Stradomski
Paweł Stradomski kirjoitti:
W liście Rasmus Lerdorf z dnia poniedziałek, 21 lipca 2008:
It also isn't any shorter:
if(str_endswith($path,'.php'))
vs.
if(substr($path,-4)=='.php')
Only if comparing to a static string, but not for this case:
if (substr($path, -strlen($extension)) == $extension)
Readability would also increase.
You people are funny..
--Jani
Jani Taskinen wrote:
Paweł Stradomski kirjoitti:
W liście Rasmus Lerdorf z dnia poniedziałek, 21 lipca 2008:
It also isn't any shorter:
if(str_endswith($path,'.php'))
vs.
if(substr($path,-4)=='.php')
Only if comparing to a static string, but not for this case:
if (substr($path, -strlen($extension)) == $extension)
Readability would also increase.
You people are funny..
I'd like to have such a function in PHP, but when you think about how
easy it is to create without bloating the PHP core, it's easy enough to
do without it. Here's what I do using my own string library:
if (LS_Util_String :: ends_with($path, '.php')) {
...
}
It's a bit longer, but all my functions are longer for good reason:
http://www.dantescode.com/2007/10/10/evolution-of-php-coder-naming-classes/
-- Dante
W liście Rasmus Lerdorf z dnia poniedziałek, 21 lipca 2008:
It also isn't any shorter:
if(str_endswith($path,'.php'))
vs.
if(substr($path,-4)=='.php')
Only if comparing to a static string, but not for this case:
if (substr($path, -strlen($extension)) == $extension)
Then $extension is a CV which isn't that much slower in comparison as a
CONST, so from engine-performance-perspective: no big deal -> spend your
time optimizing on other places where it has more effect than the time
you loose on teaching people about all the fancy string functions (where
we already have more than enough)
Readability would also increase.
too many functions hurt more on readability imo ...
johannes
Paweł Stradomski wrote:
W liście Rasmus Lerdorf z dnia poniedziałek, 21 lipca 2008:
It also isn't any shorter:
if(str_endswith($path,'.php')) vs. if(substr($path,-4)=='.php')Only if comparing to a static string, but not for this case:
if (substr($path, -strlen($extension)) == $extension)
Readability would also increase.
In our code base, we have a nice file called string.php that has every
variation of string functions not covered by the core in it. We add
stuff as we need it. I break strings on the space nearest a given
length in 80% of all code that runs on my server. But, I don't expect a
PHP built in to do it. If you are worried about performance, you could
make a PECL Strings package for all the stuff that the core does not do.
Then, your code can be readable and neat like you want.
Hmm, perhaps there is a need for a "standard" (widely used?) PHP
(non-OO) package that filled in the gaps that the core does not provide.
Make it non-OO so that it looks and acts like the core as much as
possible. In my "spare time" I will start this. =)
--
Brian Moon
Senior Web Engineer
When you care enough to spend the very least.
http://dealnews.com/