# Negative string offset support - Thread: https://externals.io/message/13599 - Original archive: https://news-web.php.net/php.internals/13599 - Started by Ilia Alshanetsky on 2004-10-29T19:07:05+00:00 - Messages: 32 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/13599.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #13599 — Ilia Alshanetsky — 2004-10-29T19:07:05+00:00 URL: https://externals.io/message/13599#13599 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 --- ## #13600 — Greg Beaver — 2004-10-29T19:34:18+00:00 URL: https://externals.io/message/13599#13600 · In reply to: #13599 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 --- ## #13601 — Sterling Hughes — 2004-10-29T19:34:26+00:00 URL: https://externals.io/message/13599#13601 · In reply to: #13599 why not add it with the {} operators then? -sterling > 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 --- ## #13604 — Ilia Alshanetsky — 2004-10-29T19:37:16+00:00 URL: https://externals.io/message/13599#13604 · In reply to: #13601 Sure, I have no operator preference. Ilia Sterling Hughes wrote: > why not add it with the {} operators then? > > -sterling > > > > > > […] --- ## #13603 — Rasmus Lerdorf — 2004-10-29T20:06:39+00:00 URL: https://externals.io/message/13599#13603 · In reply to: #13601 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 > why not add it with the {} operators then? > > -sterling > > > > > […] --- ## #13602 — cm@leetspeak.org — 2004-10-29T20:08:12+00:00 URL: https://externals.io/message/13599#13602 · In reply to: #13601 Exactly what I thought when reading the original post :) - Michael > why not add it with the {} operators then? > > -sterling > > > On Fri, 29 Oct 2004 15:07:05 -0400, Ilia Alshanetsky > wrote: > > […] --- ## #13605 — Paul G — 2004-10-29T20:13:01+00:00 URL: https://externals.io/message/13599#13605 · In reply to: #13599 ----- Original Message ----- From: "Ilia Alshanetsky" To: 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 --- ## #13608 — Andi Gutmans — 2004-10-29T22:36:58+00:00 URL: https://externals.io/message/13599#13608 · In reply to: #13599 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: >----- Original Message ----- >From: "Ilia Alshanetsky" >To: >Sent: Friday, October 29, 2004 3:07 PM >Subject: [PHP-DEV] Negative string offset support > > > > […] >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 --- ## #13610 — Derick Rethans — 2004-10-29T23:04:40+00:00 URL: https://externals.io/message/13599#13610 · In reply to: #13601 > 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 --- ## #13611 — Derick Rethans — 2004-10-29T23:05:06+00:00 URL: https://externals.io/message/13599#13611 · In reply to: #13600 > Ilia Alshanetsky wrote: > > […] > > 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 --- ## #13614 — Robert Cummings — 2004-10-29T23:29:29+00:00 URL: https://externals.io/message/13599#13614 · In reply to: #13610 > > > > […] > > 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. | `------------------------------------------------------------' --- ## #13616 — Derick Rethans — 2004-10-29T23:31:59+00:00 URL: https://externals.io/message/13599#13616 · In reply to: #13614 > > > > […] > > 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 --- ## #13617 — Sterling Hughes — 2004-10-29T23:36:33+00:00 URL: https://externals.io/message/13599#13617 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 wrote: > > > > […] > > 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 --- ## #13618 — Robert Cummings — 2004-10-29T23:59:31+00:00 URL: https://externals.io/message/13599#13618 · In reply to: #13616 > > > > […] > > 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. > > > […] > *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. | `------------------------------------------------------------' --- ## #13621 — Alan Knowles — 2004-10-30T00:50:27+00:00 URL: https://externals.io/message/13599#13621 · In reply to: #13599 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: > 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 --- ## #13624 — Greg Beaver — 2004-10-30T02:44:45+00:00 URL: https://externals.io/message/13599#13624 · In reply to: #13611 Derick Rethans wrote: > > > > > […] > > > How can you *need* this, you can use `substr()` just fine. I don't *need* PHP either. any other questions? Greg --- ## #13626 — Ilia Alshanetsky — 2004-10-30T05:56:35+00:00 URL: https://externals.io/message/13599#13626 · In reply to: #13611 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 --- ## #13628 — Ilia Alshanetsky — 2004-10-30T06:20:08+00:00 URL: https://externals.io/message/13599#13628 · In reply to: #13621 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: > > 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: > > > […] --- ## #13630 — Andrey Hristov — 2004-10-30T09:10:38+00:00 URL: https://externals.io/message/13599#13630 · In reply to: #13626 Ilia Alshanetsky wrote: > Derick Rethans wrote: > > > […] > > > 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 --- ## #13633 — Ilia Alshanetsky — 2004-10-30T15:45:25+00:00 URL: https://externals.io/message/13599#13633 · In reply to: #13630 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 --- ## #13640 — Markus Fischer — 2004-10-31T00:28:32+00:00 URL: https://externals.io/message/13599#13640 · In reply to: #13633 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 --- ## #13652 — Wez Furlong — 2004-11-01T01:29:46+00:00 URL: https://externals.io/message/13599#13652 Doesn't substr($a, -1) work ? --Wez. > 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. --- ## #13653 — Greg Beaver — 2004-11-01T01:56:53+00:00 URL: https://externals.io/message/13599#13653 · In reply to: #13652 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 --- ## #13654 — Marcus Boerger — 2004-11-01T02:04:45+00:00 URL: https://externals.io/message/13599#13654 · In reply to: #13652 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. > > > […] -- Best regards, Marcus mailto:helly@php.net --- ## #13655 — Sterling Hughes — 2004-11-01T06:03:09+00:00 URL: https://externals.io/message/13599#13655 · In reply to: #13654 i hope not. this should be about what's cool for developers, the speed increase is not a compelling reason.. the debate is "does this make code easier to read/write/maintain?" I think it doesn't, and therefore am against it. -sterling > 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: > > > […] > > > […] > > > […] > > -- > Best regards, > Marcus mailto:helly@php.net --- Next page: https://externals.io/message/13599.md?page=2