For the 13th time. {} is not going away in 5.1.
From the NEWS file:
16 Nov 2005, PHP 5.1 Release Candidate 5
- Added an
E_STRICTwarning on the usage of {} for accessing of string
offsets.
(Ilia)
That is, code that has been tested with RC4 and that worked (not even a
notice on whatever error reporting level) might suddenly misbehave
(produce warnings) as of RC5.
Now don't start that stupid "disable error output on production systems"
discussion again. I want my code to work on whatever setup my customers
use and I have no control over that.
Even if it's as simple as emitting a warning - it is a stupid,
unnecessary change in the RC phase. That is about professionalism.
-mp.
16 Nov 2005, PHP 5.1 Release Candidate 5
- Added an
E_STRICTwarning on the usage of {} for accessing of string
offsets.
(Ilia)
I suggest removing that warning immediately until the matter
is resolved.
- Sascha
Sascha Schumann wrote:
16 Nov 2005, PHP 5.1 Release Candidate 5
- Added an
E_STRICTwarning on the usage of {} for accessing of string
offsets.
(Ilia)I suggest removing that warning immediately until the matter is resolved.
I second that as people on the list here are undecided about the removal
of {} for strings. Keeping that warning creates even more confusion
about a really minor issue (having two ways of accesing strings offsets).
- Chris
I second that as people on the list here are undecided about the removal
of {} for strings. Keeping that warning creates even more confusion
about a really minor issue (having two ways of accesing strings offsets).
Whilst I'm not really in favour of the change, I think that a change in PHP
like this would be far better accepted were it better documented.
The previous major change in PHP got PHP a lot of press, but I didn't read
anywhere an 'official' document as to why things were changed, explaining in
idiot-terms how to fix things, and why the fix was needed.
If this change included a simple sed command that could be applied to code to
fix 'legacy' code, and a page was put up linked form PHP.net's front page to
the documenation explaining why the change took place, then this change would
be far easier for php users to accept.
BTW, whilst on the topic, was there a document written about why the former
mentioned change was made? All I've seen is PHP developers getting stressed
and saying 'it was a needed fix', with very little justification.
Regards,
--
Ian P. Christian ~ http://pookey.co.uk
If this change included a simple sed command that could be applied to code
to fix 'legacy' code
Sorry, should have included this...
For example:
$ cat test
<?php
$moo{3};
$foo = $moo{12};
?>
$ sed -e 's/$([a-zA-Z][a-zA-Z0-9]){([0-9])}/substr($\1,\2,1)/g' test
<?php
substr($moo,3,1);
$foo = substr($moo,12,1);
?>
--
Ian P. Christian ~ http://pookey.co.uk
Ian P. Christian wrote:
If this change included a simple sed command that could be applied to code
to fix 'legacy' codeSorry, should have included this...
For example:
$ cat test
<?php$moo{3};
$foo = $moo{12};
?>
$ sed -e 's/$([a-zA-Z][a-zA-Z0-9]){([0-9])}/substr($\1,\2,1)/g' test
<?phpsubstr($moo,3,1);
$foo = substr($moo,12,1);
?>
Doesn't work to well with
$$moo{1};
or
$moo = array( 1 => 'foo');
$moo{1};
Doesn't work to well with
$$moo{1};
Didn't think of that :)
or
$moo = array( 1 => 'foo');
$moo{1};
I actaully didn't even know you could do that :)
So.. ignore my regex, but not my comment about decent docmentation for
reasoning and how to fix existing code being needed.
--
Ian P. Christian ~ http://pookey.co.uk