# deprecation status of $str{42} versus $str[42] - Thread: https://externals.io/message/38153 - Original archive: https://news-web.php.net/php.internals/38153 - Started by Philip Olson on 2008-06-10T22:27:02+00:00 - Messages: 25 - 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 --- ## #38153 — Philip Olson — 2008-06-10T22:27:02+00:00 URL: https://externals.io/message/38153#38153 Hello geeks, This email is to confirm that $str{42} is deprecated in favour of $str[42] as of PHP 6. There is some confusion so let's make something official here. A little history: - May, 2001: $str[42]: is documented as deprecated since PHP 4 - Nov, 2005: $str[42]: kept while $str{42} is instead deprecated. Discussed: - http://markmail.org/message/tmvkpknlzfij5k5o - Nov, 2005: $str{42}: 5.1 RC5 throws `E_STRICT` for $str{42} but removed before release - May, 2006: $str[42]: switches from deprecated to "preferred" in docs - Aug, 2006: $str{42}: documentation reads "deprecated as of PHP 6" Currently it emits no errors when one plan was to deprecate it in PHP 5.x and remove in PHP 6.0 but that doesn't appear the plan today. So unless this thread changes something, an `E_DEPRECATED` will be added to HEAD (PHP 6.0.0) for curly brace string access ( $str{42} ) and the documentation will remain as is. Regards, Philip --- ## #38154 — Markus Fischer — 2008-06-10T23:04:55+00:00 URL: https://externals.io/message/38153#38154 · In reply to: #38153 Hi, I don't get this deprecation and thus the forced code change at all. Considering the amount of code using this style, see http://www.google.com/codesearch?as_q=\%24[a-z][a-z0-9_]*{[^}]%2B}&hl=en&as_lang=php and given that no PHP code change has been done I would rather suggest removing the chase for deprecation in this case and remove this from the documentation and let the syntax exist that way as long as PHP lives. - Markus Philip Olson wrote: > Hello geeks, > > This email is to confirm that $str{42} is deprecated in favour of > $str[42] as of PHP 6. There is some confusion so let's make something > official here. > > A little history: > - May, 2001: $str[42]: is documented as deprecated since PHP 4 > - Nov, 2005: $str[42]: kept while $str{42} is instead deprecated. > Discussed: > - http://markmail.org/message/tmvkpknlzfij5k5o > - Nov, 2005: $str{42}: 5.1 RC5 throws `E_STRICT` for $str{42} but removed > before release > - May, 2006: $str[42]: switches from deprecated to "preferred" in docs > - Aug, 2006: $str{42}: documentation reads "deprecated as of PHP 6" > > Currently it emits no errors when one plan was to deprecate it in PHP > 5.x and remove in PHP 6.0 but that doesn't appear the plan today. > > So unless this thread changes something, an `E_DEPRECATED` will be added > to HEAD (PHP 6.0.0) for curly brace string access ( $str{42} ) and the > documentation will remain as is. > > Regards, > Philip --- ## #38155 — Lars Strojny — 2008-06-10T23:13:02+00:00 URL: https://externals.io/message/38153#38155 · In reply to: #38154 Hi Markus, Am Mittwoch, den 11.06.2008, 01:04 +0200 schrieb Markus Fischer: [...] > I don't get this deprecation and thus the forced code change at all. > Considering the amount of code using this style, see > http://www.google.com/codesearch?as_q=\%24[a-z][a-z0-9_]*{[^}]%2B}&hl=en&as_lang=php > and given that no PHP code change has been done I would rather suggest > removing the chase for deprecation in this case and remove this from the > documentation and let the syntax exist that way as long as PHP lives. I agree, unless there is a sane technical reason (problems with the parser, an ambiguity I overlook), I would rather prefer not to go on with its deprecation. It even allows to enforce [] for array- and {} for string offsets in the coding style which helps to distinguish both. cu, Lars --- ## #38156 — Jani Taskinen — 2008-06-10T23:15:40+00:00 URL: https://externals.io/message/38153#38156 · In reply to: #38154 Correct me if I'm wrong but wasn't that the last decision we made about it the last time this was brought up? Just undocument it. Totally. It exists, only works with strings (right?! :) and is not recommended. So simply make it disappear from the docs. "See no evil, hear no evil, speak no evil.." ;) --Jani Markus Fischer kirjoitti: > Hi, > > I don't get this deprecation and thus the forced code change at all. > Considering the amount of code using this style, see > http://www.google.com/codesearch?as_q=\%24[a-z][a-z0-9_]*{[^}]%2B}&hl=en&as_lang=php > > and given that no PHP code change has been done I would rather suggest > removing the chase for deprecation in this case and remove this from the > documentation and let the syntax exist that way as long as PHP lives. > > - Markus > > > Philip Olson wrote: > > […] --- ## #38157 — Paul Reinheimer — 2008-06-10T23:23:42+00:00 URL: https://externals.io/message/38153#38157 · In reply to: #38153 >So unless this thread changes something, an `E_DEPRECATED` will be added to HEAD (PHP >6.0.0) for curly brace string access ( $str{42} ) and the documentation will remain as is. I'm well aware that I don't get a vote, so I'll skip the +1. That being said, I'd like to argue in favour of depricating the curly braces. My reasoning is simple, every time a new feature is up for inclusion in the language hours/days/weeks/months are spent arguing over what characters/operators will be used in order to identify the new feature. We're out of characters.Killing the duplication now means that when PHP 7 roles around we've got two characters we can use for some killer new feature. (I'll go back to the quiet corner now) paul (preinheimer@php.net) -- Paul Reinheimer --- ## #38158 — Andi Gutmans — 2008-06-11T04:11:59+00:00 URL: https://externals.io/message/38153#38158 · In reply to: #38155 Hi, $str{} was considered a best practice for a while so as you can see via Google Code Search it's been used quite a bit. I take the blame for introducing it with the intention to not only create a better separation between arrays and string offsets but by also then allowing for a cleaner implementation for string offsets. Unfortunately I never delivered that cleaner implementation esp. as there didn't seem a huge benefit I don't have strong feelings either way esp. as moving from $str{} to $str[] is scriptable but given that so many people have used it and there are benefits to separating the two (it also resolves an ambiguity) I'd like to put another option out there which is to try and see if we can actually follow through on original intentions of also delivering technical benefit in addition to the syntax separation. Andi --- ## #38209 — Lukas Kahwe Smith — 2008-06-14T13:26:20+00:00 URL: https://externals.io/message/38153#38209 · In reply to: #38156 > Correct me if I'm wrong but wasn't that the last decision we made > about it the last time this was brought up? Just undocument it. > Totally. It exists, only works with strings (right?! :) and is not > recommended. So simply make it disappear from the docs. "See no > evil, hear no evil, speak no evil.." ;) I do not know the decision (anyone who cares about decisions being remembered should write an RFC nowadays), but I think what Jani is saying sounds reasonable to me. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #38210 — Stefan Walk — 2008-06-14T13:55:28+00:00 URL: https://externals.io/message/38153#38210 · In reply to: #38209 On Saturday 14 June 2008 15:26:20 Lukas Kahwe Smith wrote: > > > […] > > I do not know the decision (anyone who cares about decisions being > remembered should write an RFC nowadays), but I think what Jani is > saying sounds reasonable to me. > > regards, > Lukas Kahwe Smith > mls@pooteeweet.org et@edea:~> php -r '$array = array("bar"); echo $array{0},"\n";' bar So, no "only works with strings". And it has been the preferred way to deal with string offsets for years. Undocumenting it will mean a feature that is used quite a bit because of this is not to be found in the documentation. Not really a good idea. Regards, Stefan --- ## #38220 — Chris Stockton — 2008-06-14T16:14:53+00:00 URL: https://externals.io/message/38153#38220 · In reply to: #38158 Hello, > Hi, > > $str{} was considered a best practice for a while so as you can see via > Google Code Search it's been used quite a bit. > I take the blame for introducing it with the intention to not only > create a better separation between arrays and string offsets but by also > then allowing for a cleaner implementation for string offsets. > Unfortunately I never delivered that cleaner implementation esp. as > there didn't seem a huge benefit > > I don't have strong feelings either way esp. as moving from $str{} to > $str[] is scriptable but given that so many people have used it and > there are benefits to separating the two (it also resolves an ambiguity) > I'd like to put another option out there which is to try and see if we > can actually follow through on original intentions of also delivering > technical benefit in addition to the syntax separation. I personally have always used {} for string offsets because it just felt right. [] seems like it is for arrays, for me, using it on strings makes me feel dirty. Could we maybe visit some of the ideas you have had with {} syntax offering some benefit? That I do not completely understand and would be nice to know what you mean. Maybe something like built in substr? since it wouldn't break existing use of {}, tough thing is the ambiguity between {1} regular and {1} substr, dunno: $str = "abcdef"; $result = $str{1}; // returns b, but substr would be something like bcdef $result = $str{1, 2} // returns bc, this we know what to return for sure $result = $str{1,} // maybe to make up for lack of {1} returning remaining portion, its a little ugly almost feels like a syntax error Just trying to figure out how you could have technical benefit with it, maybe you just meant performance optimization or something. -Chris --- ## #38266 — Arvids Godjuks — 2008-06-16T06:16:47+00:00 URL: https://externals.io/message/38153#38266 · In reply to: #38220 IMHO, remove {} and leave [] for strings. Strings is array of chars, so [] syntax is fully OK --- ## #38267 — Arvids Godjuks — 2008-06-16T06:20:20+00:00 URL: https://externals.io/message/38153#38267 · In reply to: #38220 2008/6/14 Chris Stockton : > > I personally have always used {} for string offsets because it just felt > right. [] seems like it is for arrays, for me, using it on strings makes me > feel dirty. > > Could we maybe visit some of the ideas you have had with {} syntax offering > some benefit? That I do not completely understand and would be nice to know > what you mean. > > Maybe something like built in substr? since it wouldn't break existing use > of {}, tough thing is the ambiguity between {1} regular and {1} substr, > dunno: > $str = "abcdef"; > $result = $str{1}; // returns b, but substr would be something like bcdef > $result = $str{1, 2} // returns bc, this we know what to return for sure > $result = $str{1,} // maybe to make up for lack of {1} returning remaining > portion, its a little ugly almost feels like a syntax error > > Just trying to figure out how you could have technical benefit with it, > maybe you just meant performance optimization or something. > > -Chris > String is an array of chars, always was and is such in any programming language. So I see argument for {} as missing knowledge for some programming basics. And I don't understand why are you arguing on this. This was decided for removal long ago - so just do it. --- ## #38269 — Robert Cummings — 2008-06-16T06:45:55+00:00 URL: https://externals.io/message/38153#38269 · In reply to: #38267 > 2008/6/14 Chris Stockton : > > > […] > > String is an array of chars, always was and is such in any programming > language. So I see argument for {} as missing knowledge for some programming > basics. > > And I don't understand why are you arguing on this. This was decided for > removal long ago - so just do it. You must have skipped some of the messages in this thread... such as the following one: http://marc.info/?l=php-internals&m=121315757406465&w=2 Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP --- ## #38286 — Chris Stockton — 2008-06-16T14:26:00+00:00 URL: https://externals.io/message/38153#38286 · In reply to: #38267 Hello, On Sun, Jun 15, 2008 at 11:20 PM, Arvids Godjuks wrote: > String is an array of chars, always was and is such in any programming > language. So I see argument for {} as missing knowledge for some programming > basics. > > And I don't understand why are you arguing on this. This was decided for > removal long ago - so just do it. > Seems like you are missing some PHP programming basics. Strings are not an array of chars, please go back to making ping pong in java c# or whatever other little comp sci classes you took. PHP is not any of them. Foreach("foo" as $key => $char) {}, after learning, please be quiet and let andi answer my question on his ideas he had for improvements to the existing and once favored syntax. -Chris --- ## #38288 — Edward Z. Yang — 2008-06-16T14:37:08+00:00 URL: https://externals.io/message/38153#38288 · In reply to: #38286 Chris Stockton wrote: > Seems like you are missing some PHP programming basics. Strings are not an > array of chars, please go back to making ping pong in java c# or whatever > other little comp sci classes you took. PHP is not any of them. > Foreach("foo" as $key => $char) {}, after learning, please be quiet and let > andi answer my question on his ideas he had for improvements to the existing > and once favored syntax. PHP userland code may not treat strings as first class arrays, but that's certainly how they are represented internally. Anyway, it would be neat if we could get that foreach syntax to work. I get sick of for($i = 0, $c = strlen($str); $i < $c; $i++) very quickly. -- Edward Z. Yang GnuPG: 0x869C48DA HTML Purifier Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] --- ## #38311 — Arvids Godjuks — 2008-06-17T06:27:37+00:00 URL: https://externals.io/message/38153#38311 · In reply to: #38288 2008/6/16 Edward Z. Yang : > > PHP userland code may not treat strings as first class arrays, but > that's certainly how they are represented internally. > > Anyway, it would be neat if we could get that foreach syntax to work. I > get sick of for($i = 0, $c = strlen($str); $i < $c; $i++) very quickly. > > Totaly agree, the best example from the whole thread --- ## #38314 — Richard Quadling — 2008-06-17T09:01:59+00:00 URL: https://externals.io/message/38153#38314 · In reply to: #38286 2008/6/16 Chris Stockton : > Hello, > > On Sun, Jun 15, 2008 at 11:20 PM, Arvids Godjuks > […] > wrote: > > > […] > programming > > […] > > Seems like you are missing some PHP programming basics. Strings are not an > array of chars, please go back to making ping pong in java c# or whatever > other little comp sci classes you took. PHP is not any of them. > Foreach("foo" as $key => $char) {}, after learning, please be quiet and let > andi answer my question on his ideas he had for improvements to the > existing > and once favored syntax. > > -Chris > Sort of in response to "whatever other little comp sci classes you took" and sort of explaining what a user sees. I'm a self taught software developer and have been in paid employment for over 20 years and only in 2 jobs. So, even if I don't know everything about PHP's internals, my skills are good enough not to get me fired. In that time, I've used (to a different amount) COBOL, Sage Retrieve 4GL, C, Delphi, JS, PHP, MS DOS Batch files. In nearly all of these languages a "string" is a series of characters which can be accessed via an offset from the beginning of the "string". In many cases the syntax is the same as that of accessing an array element. In the languages where it is necessary to define the length of the string, defining an array and a string are done in similar ways. Not identically by any means, but the "user" impression is that they are similar. The example Chris gave was for iterating an array. Strings cannot be iterated in the same manner, but that doesn't mean you cannot traverse a string and an array in the same way. 2008/6/16 Edward Z. Yang : > > […] > > Totaly agree, the best example from the whole thread You're not learning from the mistakes of other languages (ruby in this case, which removed Enumerable from String in 1.9) ... "foreach" makes no sense for strings, because it's unclear what you want (with unicode terminology here, as this is for php6): "for each byte" "for each codeunit" "for each codepoint", or "for each line", or ... if you want to use foreach in your example, just do foreach (str_split($str) as $value) { ... Regards, Stefan --- ## #38315 — Steph Fox — 2008-06-17T09:21:49+00:00 URL: https://externals.io/message/38153#38315 · In reply to: #38286 Hi, > Seems like you are missing some PHP programming basics. Strings are not an > array of chars, please go back to making ping pong in java c# or whatever > other little comp sci classes you took. PHP is not any of them. > Foreach("foo" as $key => $char) {}, after learning, please be quiet and > let > andi answer my question on his ideas he had for improvements to the > existing > and once favored syntax. Please, keep this kind of personal abuse off the core development list. It adds absolutely nothing to the debate, and we're all very, very bored with it. Thanks, - Steph --- ## #38321 — Edward Z. Yang — 2008-06-17T11:35:05+00:00 URL: https://externals.io/message/38153#38321 · In reply to: #38316 Stefan Walk wrote: > You're not learning from the mistakes of other languages (ruby in this case, > which removed Enumerable from String in 1.9) ... "foreach" makes no sense for > strings, because it's unclear what you want (with unicode terminology here, > as this is for php6): > "for each byte" "for each codeunit" "for each codepoint", or "for each line", > or ... You bring up a good point. However, as a counterpoint, Python does allow strings to be used as arrays: s = 'asdf' for c in s: print c In my opinion, it only makes sense for foreach to emulate the code snippet I posted above: for binary strings, that means byte-by-byte, and for Unicode strings, that means codepoint by codepoint. But as I said, it would be "neat." This is by no means an essential feature, and I probably wouldn't be able to use it anyway for BC concerns. > if you want to use foreach in your example, just do > foreach (str_split($str) as $value) { ... I would never do that, because it requires allocating an entire another PHP array, more than doubling memory usage, just to iterate across a string. If I'm doing this sort of heavy string processing, I probably need some semblance of performance. -- Edward Z. Yang GnuPG: 0x869C48DA HTML Purifier Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] --- ## #38326 — Chris Stockton — 2008-06-17T16:43:32+00:00 URL: https://externals.io/message/38153#38326 · In reply to: #38315 > > Hi, > > Seems like you are missing some PHP programming basics. Strings are not an > > […] > > Please, keep this kind of personal abuse off the core development list. It > adds absolutely nothing to the debate, and we're all very, very bored with > it I was trying to have a productive discussion on the topic, his response is the one that added no value, was nothing but a troll. Anyways, I like the fact my response brought up iterating strings, which I think as far as code points or bytes etc, go, really its the same problem as $str{0} on a Unicode string, im sure PHP6 will fix this with Unicode strings. Still, I wish this was not being removed I have a lot of legacy code around that uses it and am sure many companies do as well, and it has always felt more correct _to_me_ but it is what it is. Case closed I guess. -Chris --- ## #38369 — Andrei Zmievski — 2008-06-19T00:03:16+00:00 URL: https://externals.io/message/38153#38369 · In reply to: #38311 Maybe TextIterator can be backported from HEAD, because it allows for just that. foreach (new TextIterator($str) as $c) { ... } Arvids Godjuks wrote: > 2008/6/16 Edward Z. Yang : > > > […] > Totaly agree, the best example from the whole thread --- ## #38370 — Stanislav Malyshev — 2008-06-19T00:07:03+00:00 URL: https://externals.io/message/38153#38370 · In reply to: #38369 Hi! > Maybe TextIterator can be backported from HEAD, because it allows for > just that. > > foreach (new TextIterator($str) as $c) { > ... > } That'd be a nice addition to intl extension, too - if we implement all functionality. Any volonteers? :) Problem there would be that it would be somewhat slower - characters would have to be converted from Unicode to UTF-8 on each cycle - if we use ICU iterators (not necessary for simple cases I guess). But having it in 5.x would help some people, I guess. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #38371 — Edward Z. Yang — 2008-06-19T00:27:48+00:00 URL: https://externals.io/message/38153#38371 · In reply to: #38369 Andrei Zmievski wrote: > Maybe TextIterator can be backported from HEAD, because it allows for > just that. > > foreach (new TextIterator($str) as $c) { > ... > } IIRC, TextIterator is specifically designed for Unicode, letting you iterate over codepoints, combining sequences, characters, words, etc. So making it do all that would only make sense with intl, and even then not really (as Stanislav points out performance-wise). What I was suggesting was a shortcut to iterating over binary data; i.e. byte by byte. -- Edward Z. Yang GnuPG: 0x869C48DA HTML Purifier Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] --- ## #38373 — Andrei Zmievski — 2008-06-19T00:57:10+00:00 URL: https://externals.io/message/38153#38373 · In reply to: #38371 Yes, and we can have TextIterator work on binary strings as well (perhaps by adding TextIterator::BYTE constant). -Andrei Edward Z. Yang wrote: > Andrei Zmievski wrote: > > […] > > IIRC, TextIterator is specifically designed for Unicode, letting you > iterate over codepoints, combining sequences, characters, words, etc. So > making it do all that would only make sense with intl, and even then not > really (as Stanislav points out performance-wise). > > What I was suggesting was a shortcut to iterating over binary data; i.e. > byte by byte. --- ## #38421 — Andrei Zmievski — 2008-06-19T17:57:37+00:00 URL: https://externals.io/message/38153#38421 · In reply to: #38316 That's why there is TextIterator. And it's also much faster (in PHP 6) than iterating through string using indexes. -Andrei Stefan Walk wrote: > On Tuesday 17 June 2008 08:27:37 Arvids Godjuks wrote: > > […] > > > You're not learning from the mistakes of other languages (ruby in this case, > which removed Enumerable from String in 1.9) ... "foreach" makes no sense for > strings, because it's unclear what you want (with unicode terminology here, > as this is for php6): > "for each byte" "for each codeunit" "for each codepoint", or "for each line", > or ... if you want to use foreach in your example, just do > foreach (str_split($str) as $value) { ... > > Regards, > Stefan