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_STRICTfor $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
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_STRICTfor $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_DEPRECATEDwill be added
to HEAD (PHP 6.0.0) for curly brace string access ( $str{42} ) and the
documentation will remain as is.Regards,
Philip
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
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
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 benefitI 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
IMHO, remove {} and leave [] for strings. Strings is array of chars, so []
syntax is fully OK
2008/6/14 Chris Stockton chrisstocktonaz@gmail.com:
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 errorJust 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.
2008/6/14 Chris Stockton chrisstocktonaz@gmail.com:
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 errorJust 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.
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
Hello,
On Sun, Jun 15, 2008 at 11:20 PM, Arvids Godjuks arvids.godjuks@gmail.com
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
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 http://htmlpurifier.org Anti-XSS Filter
[[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
2008/6/16 Edward Z. Yang edwardzyang@thewritingpot.com:
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
On Tuesday 17 June 2008 08:27:37 Arvids Godjuks wrote:
2008/6/16 Edward Z. Yang edwardzyang@thewritingpot.com:
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
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
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 http://htmlpurifier.org Anti-XSS Filter
[[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
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:
2008/6/16 Edward Z. Yang edwardzyang@thewritingpot.com:
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 threadYou'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
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 edwardzyang@thewritingpot.com:
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
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
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 http://htmlpurifier.org Anti-XSS Filter
[[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
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:
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.
2008/6/16 Chris Stockton chrisstocktonaz@gmail.com:
Hello,
On Sun, Jun 15, 2008 at 11:20 PM, Arvids Godjuks <arvids.godjuks@gmail.com
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
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.
<?php
$a = array(1,2,3,5,7,11,13,17,19);
$s = 'abcegkmqs';
for ($i = 0 ; $i < 9 ; ++$i) {
echo $a[$i], ' vs ', $s[$i], ' vs ', $s{$i}, PHP_EOL;
}
outputs ...
1 vs a vs a
2 vs b vs b
3 vs c vs c
5 vs e vs e
7 vs g vs g
11 vs k vs k
13 vs m vs m
17 vs q vs q
19 vs s vs s
So, using the same syntax to access a string and an array, from a user's
perspective, does suggest that a string is an array of characters.
Please be a little more forgiving of users.
My only criticism against the use of $s{$i} is that { } is used to "wrap"
compound statements (say like begin / end in other languages/syntaxes). With
that in mind, you should be able to put statements which have a return value
of some sort which is then used to access the appropriate element. But I
think that is getting very close to closures.
$s{return some_complex_calc();}
sort of thing (smells like JS).
I would like this syntax as I don't want to create a real function for just
1 use - the function may not be reuseable, so it doesn't need to get into
the namespace. But I think that's a different argument.
So, to all the devs who read my missives, keep up the good work. I'm paid
because of the work you do. Your efforts make my life easier.
Thank you,
Richard Quadling.
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
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
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
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
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=phpand 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_STRICTfor $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_DEPRECATEDwill be added
to HEAD (PHP 6.0.0) for curly brace string access ( $str{42} ) and the
documentation will remain as is.Regards,
Philip
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
On Saturday 14 June 2008 15:26:20 Lukas Kahwe Smith wrote:
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
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
So unless this thread changes something, an
E_DEPRECATEDwill 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