Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Negative string offset support »

Negative string offset support

php.internals

Ilia A.

21 years ago
I am wondering what are people's opinions on adding support for negative string offsets that could be used to access data from the end of a string. Ex. $a = "123"; echo $a[-1]; // would print 3 I don't think we should do this for arrays, since -1 and similar are valid array keys, which means adding this support for arrays would break BC. Ilia

Greg Beaver

21 years ago
Ilia Alshanetsky wrote:
> I am wondering what are people's opinions on adding support for negative > string offsets that could be used to access data from the end of a string. > > Ex. $a = "123"; echo $a[-1]; // would print 3 > > I don't think we should do this for arrays, since -1 and similar are > valid array keys, which means adding this support for arrays would break > BC.
I need this, +1 Greg

Derick Rethans

21 years ago
On Fri, 29 Oct 2004, Greg Beaver wrote:
> Ilia Alshanetsky wrote: > > I am wondering what are people's opinions on adding support for negative > > string offsets that could be used to access data from the end of a string. > > > > Ex. $a = "123"; echo $a[-1]; // would print 3 > > > > I don't think we should do this for arrays, since -1 and similar are > > valid array keys, which means adding this support for arrays would break > > BC. > > I need this, +1
How can you *need* this, you can use substr() just fine. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Greg Beaver

21 years ago
Derick Rethans wrote:
> On Fri, 29 Oct 2004, Greg Beaver wrote: > > >>Ilia Alshanetsky wrote: >> >>>I am wondering what are people's opinions on adding support for negative >>>string offsets that could be used to access data from the end of a string. >>> >>>Ex. $a = "123"; echo $a[-1]; // would print 3 >>> >>>I don't think we should do this for arrays, since -1 and similar are >>>valid array keys, which means adding this support for arrays would break >>>BC. >> >>I need this, +1 > > > How can you *need* this, you can use substr() just fine.
I don't *need* PHP either. any other questions? Greg

Ilia A.

21 years ago
Derick Rethans wrote:
> How can you *need* this, you can use substr() just fine.
Almost no peace of functionality in PHP in unique, some extensions duplicate core/standard functionality and vice versa. Usually the "core" offers a simpler access to a resource and full pledged extensions gives the full capabilities. The best example of this is streams, sockets extension and cURL. On a similar note, most users don't use even 1/2 the functionality PHP offers, does it mean we should remove those parts of the language or not have add them in the 1st place? Just because substr() or $a[strlen($a) - 1] would work, it does not mean they are the most optimal approaches. The change to permit negative string offsets would require @ most 2-3 line change in Zend and it would be trivial to write a series of tests to cover the affected code. We are not talking about a major change here. Ilia

Andrey Hristov

21 years ago
Ilia Alshanetsky wrote:
> Derick Rethans wrote: > >> How can you *need* this, you can use substr() just fine. > > > Almost no peace of functionality in PHP in unique, some extensions > duplicate core/standard functionality and vice versa. Usually the "core" > offers a simpler access to a resource and full pledged extensions gives > the full capabilities. The best example of this is streams, sockets > extension and cURL. > > On a similar note, most users don't use even 1/2 the functionality PHP > offers, does it mean we should remove those parts of the language or not > have add them in the 1st place? > > Just because substr() or $a[strlen($a) - 1] would work, it does not > mean they are the most optimal approaches. The change to permit negative > string offsets would require @ most 2-3 line change in Zend and it would > be trivial to write a series of tests to cover the affected code. We are > not talking about a major change here. > > Ilia >
Privet Ilia, Andy mentioned that he tried in the past to separate {} and [] but after some unsuccess he left the idea of separating. So, the patch definitely won't be 2-3 lines of code. There are a lot of people which don't know about negative offsets at all, and use strlen() for calculations. Moving this feature to the language itself won't help them that much if just don't read the documentation ( as they do). Andrey

Ilia A.

21 years ago
Andrey Hristov wrote:
> Andy mentioned that he tried in the past to separate {} and [] but after > some unsuccess he left the idea of separating. So, the patch definitely > won't be 2-3 lines of code.
I am well aware that at this point PHP has no separation between [] and {} as far as string offsets go. My initial suggestion was to add the support for negative offsets and not to limit it to a particular construct. Given that this is intended for strings only, I readily agreed with people who suggested that it should be available only for {}, assuming there was a separation.
> There are a lot of people which don't know about negative offsets at all, > and use strlen() for calculations. Moving this feature to the language > itself won't help them that much if just don't read the documentation ( > as they do).
Almost any new function/construct/extension begins from obscurity. Even people who know about it won't use it till enough PHP versions have been released with it, because they'd up limit their apps to "latest and greatest". Ilia

Markus Fischer

21 years ago
Ilia Alshanetsky wrote:
> I am well aware that at this point PHP has no separation between [] and > {} as far as string offsets go. My initial suggestion was to add the > support for negative offsets and not to limit it to a particular > construct. Given that this is intended for strings only, I readily > agreed with people who suggested that it should be available only for > {}, assuming there was a separation.
What happens to arrays when there's no difference between [] and {} ? $array[-1] $string[-1] This will confused people because $array[-1] actually wouldn't return the last element (it could, if we know the indices are only positive integers, but we can't assume when that when using arrays with arbitrary keys -> hashes). That seems problematic to me. - Markus

Andi Gutmans

21 years ago
At 01:05 AM 10/30/2004 +0200, Derick Rethans wrote:
>On Fri, 29 Oct 2004, Greg Beaver wrote: > > > Ilia Alshanetsky wrote: > > > I am wondering what are people's opinions on adding support for negative > > > string offsets that could be used to access data from the end of a > string. > > > > > > Ex. $a = "123"; echo $a[-1]; // would print 3 > > > > > > I don't think we should do this for arrays, since -1 and similar are > > > valid array keys, which means adding this support for arrays would break > > > BC. > > > > I need this, +1 > >How can you *need* this, you can use substr() just fine.
Yeah, I also thought the word "need" is a bit strong :) It's more like "syntactic sugar which is nice-to-have" Andi

Derick Rethans

21 years ago
On Fri, 29 Oct 2004, Andi Gutmans wrote:
> Yeah, I also thought the word "need" is a bit strong :) It's more like > "syntactic sugar which is nice-to-have"
As I just told Ilia on IRC, I think we should not add this (now) for a couple of reasons: - Adding new language constructs in mini releases is IMO not the way to go as it will make it possible impossible to run script that use this new construct not even parse on PHP 5.0.x servers. Adding normal new functions does not have this problem of course, as those scripts are still parsable. - Substring works just fine, adding this for performance reasons is IMO invalid. - People might want to take this even further and request {1,3}, {-3,2} and the like. (This was expressed in the past when talking about this stuff) regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Sterling Hughes

21 years ago
I think we should not follow this discussion on internals@ and instead we should have a subcommittee to study whether or not the word need was appropriate in the context of the substring operator, or whether in fact, "would be nice to have, but might be able to continue living" would've been a more appropriate form of expression. -Sterling On Sat, 30 Oct 2004 01:29:46 +0200 (CEST), Derick Rethans <derick@php.net> wrote:

Robert Cummings

21 years ago
On Fri, 2004-10-29 at 19:29, Derick Rethans wrote:
> On Fri, 29 Oct 2004, Andi Gutmans wrote: > > > Yeah, I also thought the word "need" is a bit strong :) It's more like > > "syntactic sugar which is nice-to-have" > > As I just told Ilia on IRC, I think we should not add this (now) for a > couple of reasons: > > - Adding new language constructs in mini releases is IMO not the way to > go as it will make it possible impossible to run script that use this > new construct not even parse on PHP 5.0.x servers. Adding normal new > functions does not have this problem of course, as those scripts are > still parsable. > - Substring works just fine, adding this for performance reasons is IMO > invalid. > - People might want to take this even further and request {1,3}, {-3,2} > and the like. (This was expressed in the past when talking about this > stuff)
Reading this after writing my comment about speed. If I could get a substring at 50% of the current substring function's time cost because the above operator existed then I'd be all over it. While I agree syntax is an issue because the PHP developers want to keep the language very clear so that clueless newbies don't get confused, considering the {} operator has only one purpose right now for strings, I don't think the above concept would be at all hurtful to the PHP philosophy. Cheers, Rob.
-- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------'

Robert Cummings

21 years ago
On Fri, 2004-10-29 at 19:29, Derick Rethans wrote:
> On Fri, 29 Oct 2004, Andi Gutmans wrote: > > > Yeah, I also thought the word "need" is a bit strong :) It's more like > > "syntactic sugar which is nice-to-have" > > As I just told Ilia on IRC, I think we should not add this (now) for a > couple of reasons: > > - Adding new language constructs in mini releases is IMO not the way to > go as it will make it possible impossible to run script that use this > new construct not even parse on PHP 5.0.x servers. Adding normal new > functions does not have this problem of course, as those scripts are > still parsable.
BTW, I agree with the above argument... not that my agreeing or disagreeing counts for much :) Cheers, Rob.
-- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------'

Sara Golemon

21 years ago
> - Adding new language constructs in mini releases is IMO not the way to > go as it will make it possible impossible to run script that use this > new construct not even parse on PHP 5.0.x servers. Adding normal new > functions does not have this problem of course, as those scripts are > still parsable. >
I agree that it introduces the problem of individuals writing scripts which rely on this feature then publishing them and other users getting hurt/angry/confused when it doesn't work. However, I don't think that a major version (4->5) is any better than a minor version (5.0->5.1) as more than a few people are having issues with PHP5 specific OOP code breaking in 4.3 installations (i.e. PPP access modifiers). Though to be fair... This doesn't prevent the scripts from parsing, it just makes then behave incorectly (probably worse overall, but there is a distinction).
> - Substring works just fine, adding this for performance reasons is IMO > invalid. >
Absolutely, were a feature like this introduced, I (personally) would continue to use substr($str, -1) for at least a couple minor versions to come in the name of BC. However, when those extra couple minor versions have passed, I'd feel much better about using a feature that's "been around since the 5.1 days"... silly though it may be.
> - People might want to take this even further and request {1,3}, {-3,2} > and the like. (This was expressed in the past when talking about this > stuff) >
They might... and the response to that is that it's a more siginificant modification/glut of the exisiting code than merely allowing negative offsets. The fact is allowing negative string offsets via the {} operator involves changing one line, and it's no major waste of CPU cycles. Full substr()esque behavior would be more bloat-intensive of course and I'd be inclined to side against that. -Sara Index: Zend/zend_execute.c =================================================================== RCS file: /repository/ZendEngine2/zend_execute.c,v retrieving revision 1.684 diff -u -r1.684 zend_execute.c --- Zend/zend_execute.c 22 Oct 2004 21:42:14 -0000 1.684 +++ Zend/zend_execute.c 30 Oct 2004 00:46:13 -0000 @@ -1210,7 +1210,7 @@ container = *container_ptr; result->str_offset.str = container; PZVAL_LOCK(container); - result->str_offset.offset = dim->value.lval; + result->str_offset.offset = dim->value.lval >= 0 ? dim->value.lval : (dim->value.lval + container->value.str.len); result->var.ptr_ptr = NULL; if (type == BP_VAR_R || type == BP_VAR_IS) { AI_USE_PTR(result->var);

Andi Gutmans

21 years ago
Nah that patch won't do because it'll effect [] also. It's more complicated than that. I've tried separating them in the past and it was annoying (and didn't have time to finish it off). Andi At 05:51 PM 10/29/2004 -0700, Sara Golemon wrote:

Sara Golemon

21 years ago
"Andi Gutmans" <andi@zend.com> wrote in message news:5.1.0.14.2.20041029180202.043971b0@localhost...
> Nah that patch won't do because it'll effect [] also. > It's more complicated than that. I've tried separating them in the past > and it was annoying (and didn't have time to finish it off). > > Andi >
True... I should have mentioned that I don't personally see a problem with it working in both modes. :) -Sara

Ilia A.

21 years ago
Derick Rethans wrote:
> - Adding new language constructs in mini releases is IMO not the way to > go as it will make it possible impossible to run script that use this > new construct not even parse on PHP 5.0.x servers. Adding normal new > functions does not have this problem of course, as those scripts are > still parsable.
IMO a mini release is a Z.X.Y not a Z.X release. The 5.1 release in particular introduces far more reaching changes already then this minor feature I am suggesting.
> - Substring works just fine, adding this for performance reasons is IMO > invalid.
I presume you have some benchmarks to prove this, I'd very much like to see those.
> - People might want to take this even further and request {1,3}, {-3,2} > and the like. (This was expressed in the past when talking about this > stuff)
This functionality that you mention is not even on the table, we are talking about a very specific feature. If someone wanted {1,3} and similar support it would be a completely separate matter. Ilia

moshe doron

21 years ago
Derick Rethans wrote:
> On Fri, 29 Oct 2004, Andi Gutmans wrote: > > >>Yeah, I also thought the word "need" is a bit strong :) It's more like >>"syntactic sugar which is nice-to-have" > > > As I just told Ilia on IRC, I think we should not add this (now) for a > couple of reasons: > > - Adding new language constructs in mini releases is IMO not the way to > go as it will make it possible impossible to run script that use this > new construct not even parse on PHP 5.0.x servers. Adding normal new > functions does not have this problem of course, as those scripts are > still parsable. > - Substring works just fine, adding this for performance reasons is IMO > invalid. > - People might want to take this even further and request {1,3}, {-3,2} > and the like. (This was expressed in the past when talking about this > stuff)
where the problem about 'taking it ever further'? I'm +1 for {-1} and more +1 for {-4,2} python likeness. Moshe.

Rasmus Lerdorf

21 years ago
On Sun, 31 Oct 2004, moshe doron wrote:
> where the problem about 'taking it ever further'? > I'm +1 for {-1} and more +1 for {-4,2} python likeness.
That starts getting confusing. I assume that translates to the 3rd and 4th chars from the end of the string. And, to verify that I went and looked it up and it turns out that's not the case in Python. They use [start_index:end_index] so [-4:2] would be the 4th char from the end until the 2nd char in the string, so for a 6 char string or longer that would return nothing, but worse, my initial guess at what it did was wrong. I don't like features where my first guess at what something does is wrong. -Rasmus

Marcus Börger

21 years ago
Hello Rasmus, Sunday, October 31, 2004, 11:27:40 PM, you wrote:
> On Sun, 31 Oct 2004, moshe doron wrote: >> where the problem about 'taking it ever further'? >> I'm +1 for {-1} and more +1 for {-4,2} python likeness.
> That starts getting confusing. I assume that translates to the 3rd and > 4th chars from the end of the string. And, to verify that I went and > looked it up and it turns out that's not the case in Python. They use > [start_index:end_index] so [-4:2] would be the 4th char from the end until > the 2nd char in the string, so for a 6 char string or longer that would > return nothing, but worse, my initial guess at what it did was wrong. I > don't like features where my first guess at what something does is wrong.
Same from here. If we do it it should behave like a short form of substr. Best regards, Marcus mailto:helly@php.net

Greg Beaver

21 years ago
Marcus Boerger wrote:
> Hello Rasmus, > > Sunday, October 31, 2004, 11:27:40 PM, you wrote: > > >>On Sun, 31 Oct 2004, moshe doron wrote: >> >>>where the problem about 'taking it ever further'? >>>I'm +1 for {-1} and more +1 for {-4,2} python likeness. > > >>That starts getting confusing. I assume that translates to the 3rd and >>4th chars from the end of the string. And, to verify that I went and >>looked it up and it turns out that's not the case in Python. They use >>[start_index:end_index] so [-4:2] would be the 4th char from the end until >>the 2nd char in the string, so for a 6 char string or longer that would >>return nothing, but worse, my initial guess at what it did was wrong. I >>don't like features where my first guess at what something does is wrong. > > > Same from here. If we do it it should behave like a short form of substr.
{} returns a single character a certain offset from 0, I don't see any reason to implement any of substr's advanced features. $a{3} returns the 4th character. $a{-3} would return the 4th character from the end. Simple, end of story. It would reduce the errors I inevitably get whenever using a complex feature like substr(). The three choices: 1) substr($a, strlen($a) - 1); 2) $a{strlen($a) - 1} 3) $a{-1} It's pretty obvious that the 3rd choice lowers the potential for all kinds of bugs (mistypign, wrong parameter name, incorrect parameter placement), and is much more readable. For those who already know how {} works in PHP, it's also obvious what it does at the first look without any speculation. Greg

Wez Furlong

21 years ago
Doesn't substr($a, -1) work ? --Wez. On Sun, 31 Oct 2004 17:45:03 -0500, Greg Beaver <cellog@php.net> wrote:

Greg Beaver

21 years ago
Wez Furlong wrote:
> Doesn't substr($a, -1) work ?
I knew that looked funny, but couldn't figure out why for some reason, thanks for the good catch. Greg

Marcus Börger

21 years ago
Hello Wez, well it would. However 5.1 aims to be a major speed improvement and that's what the idea is about. best regards marcus Monday, November 1, 2004, 2:29:46 AM, you wrote:
> Doesn't substr($a, -1) work ?
> --Wez.
> On Sun, 31 Oct 2004 17:45:03 -0500, Greg Beaver <cellog@php.net> wrote: >> It would reduce the errors I inevitably get >> whenever using a complex feature like substr(). The three choices: >> >> 1) substr($a, strlen($a) - 1); >> 2) $a{strlen($a) - 1} >> 3) $a{-1} >> >> It's pretty obvious that the 3rd choice lowers the potential for all >> kinds of bugs (mistypign, wrong parameter name, incorrect parameter >> placement), and is much more readable. For those who already know how >> {} works in PHP, it's also obvious what it does at the first look >> without any speculation.
-- Best regards, Marcus mailto:helly@php.net

Shane Caraveo

21 years ago
Rasmus Lerdorf wrote:
> On Sun, 31 Oct 2004, moshe doron wrote: > >> where the problem about 'taking it ever further'? I'm +1 for {-1} >> and more +1 for {-4,2} python likeness. > > > That starts getting confusing.
Having my python hat on... (some of this is just general comment after reading too much of this thread) Yeah, if that actually worked that way in python, it would be confusing. You cannot do: a="asdfghjkasdfghjk" a[-4:2] You get an empty string. That is because, as you said, it has to be start:end. a[2:-4] works and the result is of course "dfghjkasdf". You also cannot write to this: a[2:4]="asdf" That will throw an exception, as it should for apparent reasons. Negative index in strings and arrays are extremely usefull, and I use them a lot, but for some reason can never think why I use them. Thats probably because it's not tied to any particular type of operation. There also is this which is very useful for the reason that you do not have to calcuate length in your script (in the second two examples): a[:2] (grab the first two chars) a[2:] (everything after the first two chars) a[-2:] (grab the last two chars) For python, it's a great construct both for readability and performance. PHP would only benefit from the ability to use this. However, it should be of course, not be in a micro release. It is also unlikely many people will use it since it would not be backwards compatible code. Shane

Paul G

21 years ago
----- Original Message ----- From: "Shane Caraveo" <shane@caraveo.com> To: <internals@lists.php.net> Sent: Monday, November 01, 2004 1:41 PM Subject: Re: [PHP-DEV] Re: Negative string offset support --- snip --
> Having my python hat on... >
> There also is this which is very useful for the reason that you do not > have to calcuate length in your script (in the second two examples): > > a[:2] (grab the first two chars) > a[2:] (everything after the first two chars) > a[-2:] (grab the last two chars) > > For python, it's a great construct both for readability and performance. > PHP would only benefit from the ability to use this. However, it > should be of course, not be in a micro release. It is also unlikely > many people will use it since it would not be backwards compatible code.
imo, the reason this is so very useful in python is because you get to use it with strings, arrays and dictionaries (tuples as well?). while getting it for strings is better than nothing, having it work with everything would be very sweet from a syntactic sugar/easy to read/more expressive standpoint. realizing-that-i-might-just-have-killed-the-feature-request-by-asking-for-mo re-stuff-ly, paul

Zeev Suraski

21 years ago
At 08:02 30/10/2004, Ilia Alshanetsky wrote:
>Derick Rethans wrote: >>- Adding new language constructs in mini releases is IMO not the way to >> go as it will make it possible impossible to run script that use this >> new construct not even parse on PHP 5.0.x servers. Adding normal new >> functions does not have this problem of course, as those scripts are >> still parsable. > >IMO a mini release is a Z.X.Y not a Z.X release. The 5.1 release in >particular introduces far more reaching changes already then this minor >feature I am suggesting. > >>- Substring works just fine, adding this for performance reasons is IMO >> invalid. > >I presume you have some benchmarks to prove this, I'd very much like to >see those.
His point (I believe) is that introducing this patch for performance reasons, regardless of whether it makes a big difference or not, is invalid. He's not saying that it won't improve performance - he's saying that adding this with performance being the key reason is wrong. As in the past, I very much agree with this principle. Performance should play little if any role in our decision to add language-level operators. I have no strong opinion either way about this syntax addition in particular, but I lean in favour of adding it. I think it's a nice-to-have, that might actually be useful by clarifying code, rather than (by just) speeding it up. One advantage that this syntax has over other suggestions we've seen in the past is that it is quite easy to figure out what it does (either by guessing or checking), and once established, can actually result in more readable code. Zeev

Sterling Hughes

21 years ago
why not add it with the {} operators then? -sterling On Fri, 29 Oct 2004 15:07:05 -0400, Ilia Alshanetsky <ilia@prohost.org> wrote:

Michael Walter

21 years ago
Exactly what I thought when reading the original post :) - Michael

Rasmus Lerdorf

21 years ago
Right, I was about to say that too. If we only did it for the {} operator it would encourage people to use that little-used operator thereby removing a source of confusion and at the same time the BC issues are minimal. -Rasmus On Fri, 29 Oct 2004, Sterling Hughes wrote:

Ilia A.

21 years ago
Sure, I have no operator preference. Ilia Sterling Hughes wrote:

Derick Rethans

21 years ago
On Fri, 29 Oct 2004, Sterling Hughes wrote:
> why not add it with the {} operators then?
Yeah, [] is for arrays, {} for string indexes though I still think this should not be in, one can use substring for this. Something like a "negative string index" is IMO too much magic. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Robert Cummings

21 years ago
On Fri, 2004-10-29 at 19:04, Derick Rethans wrote:
> On Fri, 29 Oct 2004, Sterling Hughes wrote: > > > why not add it with the {} operators then? > > Yeah, [] is for arrays, {} for string indexes though I still think this > should not be in, one can use substring for this. Something like a > "negative string index" is IMO too much magic.
Just as much magic as the negative start in substr() function. It would be consistent with substr() precedent of negative indexes counting backward from end of string. Also, everyone knows functions run slower than operators :) Cheers, Rob.
-- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------'

Derick Rethans

21 years ago
On Fri, 29 Oct 2004, Robert Cummings wrote:
> On Fri, 2004-10-29 at 19:04, Derick Rethans wrote: > > > Yeah, [] is for arrays, {} for string indexes though I still think this > > should not be in, one can use substring for this. Something like a > > "negative string index" is IMO too much magic. > > Just as much magic as the negative start in substr() function. It would > be consistent with substr() precedent of negative indexes counting > backward from end of string.
But substr() is a *function*, that's totally different from a language construct which should be a generic tool, not a specific one like Ilia is proposing here.
> Also, everyone knows functions run slower than operators :)
*cough*bullshit argument*cough* Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Robert Cummings

21 years ago
On Fri, 2004-10-29 at 19:31, Derick Rethans wrote:
> On Fri, 29 Oct 2004, Robert Cummings wrote: > > > On Fri, 2004-10-29 at 19:04, Derick Rethans wrote: > > > > > Yeah, [] is for arrays, {} for string indexes though I still think this > > > should not be in, one can use substring for this. Something like a > > > "negative string index" is IMO too much magic. > > > > Just as much magic as the negative start in substr() function. It would > > be consistent with substr() precedent of negative indexes counting > > backward from end of string. > > But substr() is a *function*, that's totally different from a language > construct which should be a generic tool, not a specific one like Ilia > is proposing here. > > > Also, everyone knows functions run slower than operators :) > *cough*bullshit argument*cough*
Well for the amount of times you need to traverse backward in a string it probably is a crap argument :) However it does indeed stand that operators are processed faster than functions I would wager due to the overhead of setting up parameters etc. Contrast is_null( $x ) versus $x === null, there's about 17% difference in speed. Similarly (0.0 + $x) takes almost half the time of floatval( $x ). Cheers, Rob.
-- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------'

Paul G

21 years ago
----- Original Message ----- From: "Ilia Alshanetsky" <ilia@prohost.org> To: <internals@lists.php.net> Sent: Friday, October 29, 2004 3:07 PM Subject: [PHP-DEV] Negative string offset support
> I am wondering what are people's opinions on adding support for negative > string offsets that could be used to access data from the end of a string. > > Ex. $a = "123"; echo $a[-1]; // would print 3 > > I don't think we should do this for arrays, since -1 and similar are > valid array keys, which means adding this support for arrays would break
BC. this, coupled with splicing, is very useful in python. i believe it would be very useful in php as well. agree with sterling's suggestion - it would enable all of the functionality, rather than some. paul

Andi Gutmans

21 years ago
We haven't yet separated the semantics of {} and []. It was always planned but never done. I'll put it on my TODO and hopefully will find some time to look into it. Andi At 04:13 PM 10/29/2004 -0400, Paul G wrote:

Alan Knowles

21 years ago
echo $a{strlen($a)-1}; ? is that really that bad. I do worry that at present $a = "a string"; $p = 0 while( $p < strlen($p) ) .. do stuff that could do $p-- or $p++ .... echo $a{$p}; } at present that would produce a nice error if you went < 0.. easy to spot.. - if -ve was supported it could do unexpected stuff.. Regards Alan Ilia Alshanetsky wrote:

Ilia A.

21 years ago
While you are correct that invalid offset in a string will produce an error message. This error message is E_NOTICE, given that our default INI error reporting level won't display those it's arguable that very few people will see them and consequently do something about it.
> echo $a{strlen($a)-1}; ? is that really that bad.
It is not that bad, but it could be better. Basic tests I've ran show that using a strlen() is 30-40% slower and substr() is 20-25% slower then $a{-1}. Ilia Alan Knowles wrote: