My apologizes if I am bringing up a topic that has been discussed before,
this is my first time wading into the PHP developers lists and I couldn't
find anything particularly relevant with the search.
Here is a bug I submitted over the weekend (
http://bugs.php.net/bug.php?id=54387) with an
I just love substr() and I think all other languages got it wrong;)
Seriously...it behaves the same as implementations in other languages as
long as values are positive, right? how is that counter-intuitive? How
do other languages handle negative values?
Am 30.03.2011 08:06, schrieb Dan
I think when the values are positive everything is mostly great. I think
when the values are negative is where the main problems are. Both the C
function strncpy() and the C++ strings substr() function only support
positive values for length AFAIK.
I just think it is very unintuitive for the
PHP's substr() is awesome and that comes from a person that code in at least
5 different languages daily. Parsing is a problem in many real-world
problems and substr currently works great for that purpose. You work with
two parameters: offset and length of parsing. Since meaning of a negative
IMHO substr is just fine enough. It does what you expect and behaves great
on edges cases.
What I believe is that we need more high-level string abstractions (and that
includes functions as well)
substr, strpos and the like works just fine to access strings by offsets,
but when you need to work
On 30 March 2011 15:05, Hannes Landeholm landeh...@gmail.com wrote:
Parsing is a problem in many real-world
problems and substr currently works great for that purpose.
That's funny because the first thing I thought when I read the
original mail was oh that would be great for parsing. In fact,
This thread shouldn't be a criticism of substr(), it would be
pointless. Its signature and behaviour will never change, unless
perhaps around April 1st as a practical joke on the millions of
websites it would break.
That's a really good joke actually. I can imagine how angry people would
get.
On Wed Mar 30 09:05 AM, Hannes Landeholm wrote:
var_dump(\substr(foo, 5, 6) == , (string) false, false == );
Welcome to PHP. To be honest this criticism pretty much falls in the
from person that comes from another language X and is annoyed that
every little detail isn't exactly the
Hello!
While I personally like PHP's substr() an awful lot and doubt I would
use the str_slice() method, I thought I'd mention that I think what
you're proposing is much like the string.substring(from, to) method in
Javascript (and PHP's current substr() function is an awful lot like
Javascript's
Am 30.03.2011 17:54, schrieb Chad Fulton:
While I personally like PHP's substr() an awful lot
With that in mind, if this function was to be implemented, I think
that naming it substring() instead of str_slice() might make it easier
for people to pick up out of the box, since PHP developers
The example I picked in my patch was a little contrived, however I do think
it is a useful benefit for functions to work in ways people expect, even in
edge cases. There are a lot of people out there who do not know the
difference between == and ===, and I think the fact that str_slice() has one
On 30.03.11 21:36, Dan Birken wrote:
As for adding other string functions, I agree, I think there are a lot of
them that would be great to add. starts_with ends_with for sure.
Both str_startswith and str_endswith have been suggested in the past:
http://marc.info/?t=12164723011r=1w=2
I
If substr() really was so bad, then surely we'd see userland
implementations of str_slice() in every project?
Jevon
On Wed, Mar 30, 2011 at 7:06 PM, Dan Birken bir...@gmail.com wrote:
My apologizes if I am bringing up a topic that has been discussed before,
this is my first time wading into
I think most users of a language take what they are given for basic
functions like this instead of always rolling their own. I admit that both
of the changes I am suggesting here are minor, but taken together I do think
it is a significant and tangible difference (and improvement). I think if
14 matches
Mail list logo
