PHP's documentation for foreach states that if you iterate by reference
[foreach ($ii as &$i) ...], you should unset $i after the loop. $i
still points to the last element of the array - updating $i or reusing
it will update the last element of the array.
In short, why doesn't PHP automatically unset $i after the loop? I
can't think of too many cases where you would want to hold on to that
reference after you exit the loop, but I can think of a lot of scenarios
where a user could accidentally tamper the array by using $i in a
different context later on (especially since loop variable names often
are reused).
2009/12/27 Mike Wacker mwacker@cornellsun.com:
PHP's documentation for foreach states that if you iterate by reference
[foreach ($ii as &$i) ...], you should unset $i after the loop. $i still
points to the last element of the array - updating $i or reusing it will
update the last element of the array.In short, why doesn't PHP automatically unset $i after the loop? I can't
think of too many cases where you would want to hold on to that reference
after you exit the loop, but I can think of a lot of scenarios where a user
could accidentally tamper the array by using $i in a different context later
on (especially since loop variable names often are reused).
This is a bit of a FAQ, frankly. May I suggest reading this thread
from a couple of months ago:
http://marc.info/?l=php-internals&m=125617546815934&w=2. There are
some more discussions both on the list and in the bug tracker if you
want to have a bit more of a dig into this.
The really, really short version is that it would break backward
compatibility to change it now, it's useful in some (admittedly
limited) cases, and it's not as though it's not well documented as
behaving that way.
Adam
Adam Harvey wrote:
2009/12/27 Mike Wacker mwacker@cornellsun.com:
PHP's documentation for foreach states that if you iterate by reference
[foreach ($ii as &$i) ...], you should unset $i after the loop. $i still
points to the last element of the array - updating $i or reusing it will
update the last element of the array.In short, why doesn't PHP automatically unset $i after the loop? I can't
think of too many cases where you would want to hold on to that reference
after you exit the loop, but I can think of a lot of scenarios where a user
could accidentally tamper the array by using $i in a different context later
on (especially since loop variable names often are reused).This is a bit of a FAQ, frankly. May I suggest reading this thread
from a couple of months ago:
http://marc.info/?l=php-internals&m=125617546815934&w=2. There are
some more discussions both on the list and in the bug tracker if you
want to have a bit more of a dig into this.
Ah, so it seems that "reference" was the keyword I was missing in my
search queries for the bug database. It looks like I may have
(re)opened a can of worms.
The really, really short version is that it would break backward
compatibility to change it now,
I would agree that if this did change, it would have to change in PHP 6
and not 5.2/3.
it's useful in some (admittedly limited) cases,
The main problem I see is that, like you said, these cases are limited.
If you really need to hold on to a reference after the loop, then why
not make an explicit reference?
foreach ($ii as &$i) {
$j =$ $i;
// loop body
} // PHP implicitly unset()'s $i
In both this case and the status quo, someone has to add an extra line
of code for every loop. Since re-using a loop variable is a much more
common use case, I feel that PHP should accommodate that use case and
force people using references outside the loop to add the line of code
instead.
and it's not as though it's not well documented as behaving that way.
Adam
True, but it may not hurt to make the documentation more explicit to
catch the most common use case. You could add this clause: ",
especially if $value is used elsewhere as a loop variable again."
(Though should I maybe move this part into the doc newsgroup?)
Adam Harvey wrote:
2009/12/27 Mike Wacker mwacker@cornellsun.com:
PHP's documentation for foreach states that if you iterate by reference
[foreach ($ii as &$i) ...], you should unset $i after the loop. $i still
points to the last element of the array - updating $i or reusing it will
update the last element of the array.In short, why doesn't PHP automatically unset $i after the loop? I can't
think of too many cases where you would want to hold on to that reference
after you exit the loop, but I can think of a lot of scenarios where a
user
could accidentally tamper the array by using $i in a different context
later
on (especially since loop variable names often are reused).This is a bit of a FAQ, frankly. May I suggest reading this thread
from a couple of months ago:
http://marc.info/?l=php-internals&m=125617546815934&w=2. There are
some more discussions both on the list and in the bug tracker if you
want to have a bit more of a dig into this.Ah, so it seems that "reference" was the keyword I was missing in my search
queries for the bug database. It looks like I may have (re)opened a can of
worms.The really, really short version is that it would break backward
compatibility to change it now,I would agree that if this did change, it would have to change in PHP 6 and
not 5.2/3.
I would like to see this change in PHP6. :)
it's useful in some (admittedly limited) cases,
The main problem I see is that, like you said, these cases are limited. If
you really need to hold on to a reference after the loop, then why not make
an explicit reference?foreach ($ii as &$i) {
$j =$ $i;
// loop body
} // PHP implicitly unset()'s $iIn both this case and the status quo, someone has to add an extra line of
code for every loop. Since re-using a loop variable is a much more common
use case, I feel that PHP should accommodate that use case and force people
using references outside the loop to add the line of code instead.and it's not as though it's not well documented as behaving that way.
Adam
True, but it may not hurt to make the documentation more explicit to catch
the most common use case. You could add this clause: ", especially if
$value is used elsewhere as a loop variable again." (Though should I maybe
move this part into the doc newsgroup?)
We can't just randomly reset variables based on their scope in this one
specific case. If we are going to "fix" this, it should be done by
introducing a way to do proper local scope variables. Resetting a
reference simply because it is convenient in this one case would be
completely inconsistent.
-Rasmus
Ferenc Kovacs wrote:
Adam Harvey wrote:
2009/12/27 Mike Wacker mwacker@cornellsun.com:
PHP's documentation for foreach states that if you iterate by reference
[foreach ($ii as &$i) ...], you should unset $i after the loop. $i still
points to the last element of the array - updating $i or reusing it will
update the last element of the array.In short, why doesn't PHP automatically unset $i after the loop? I can't
think of too many cases where you would want to hold on to that reference
after you exit the loop, but I can think of a lot of scenarios where a
user
could accidentally tamper the array by using $i in a different context
later
on (especially since loop variable names often are reused).
This is a bit of a FAQ, frankly. May I suggest reading this thread
from a couple of months ago:
http://marc.info/?l=php-internals&m=125617546815934&w=2. There are
some more discussions both on the list and in the bug tracker if you
want to have a bit more of a dig into this.
Ah, so it seems that "reference" was the keyword I was missing in my search
queries for the bug database. It looks like I may have (re)opened a can of
worms.The really, really short version is that it would break backward
compatibility to change it now,
I would agree that if this did change, it would have to change in PHP 6 and
not 5.2/3.I would like to see this change in PHP6. :)
it's useful in some (admittedly limited) cases,
The main problem I see is that, like you said, these cases are limited. If
you really need to hold on to a reference after the loop, then why not make
an explicit reference?foreach ($ii as &$i) {
$j =$ $i;
// loop body
} // PHP implicitly unset()'s $iIn both this case and the status quo, someone has to add an extra line of
code for every loop. Since re-using a loop variable is a much more common
use case, I feel that PHP should accommodate that use case and force people
using references outside the loop to add the line of code instead.and it's not as though it's not well documented as behaving that way.
Adam
True, but it may not hurt to make the documentation more explicit to catch
the most common use case. You could add this clause: ", especially if
$value is used elsewhere as a loop variable again." (Though should I maybe
move this part into the doc newsgroup?)
Rasmus Lerdorf wrote:
We can't just randomly reset variables based on their scope in this one
specific case. If we are going to "fix" this, it should be done by
introducing a way to do proper local scope variables. Resetting a
reference simply because it is convenient in this one case would be
completely inconsistent.-Rasmus
I have some thoughts on this for PHP 6, but here's something else that
might be worth looking into.
When you write [foreach ($ii as $i) ...], you usually expect that $i is
not a reference variable (you would have used &$i otherwise). However,
PHP allows this even if $i is already a reference variable (e.g.: it was
used as such in a previous loop).
Now look at this code:
function f(&$x) {
echo $x;
}
$x = 1;
$args = array($x);
call_user_func_array('f', $args);
In PHP 5.3, this would trigger a warning and cause $x to be NULL inside
of f because you mixed value and reference types in an improper way.
This foreach() issue is essentially being caused by a similar evil mix
of reference and value types. Perhaps [foreach ($ii as $i)] should
trigger a warning if $i already exists as a reference variable.
"Rasmus Lerdorf" rasmus@lerdorf.com wrote in message
news:4B3785AC.2000507@lerdorf.com...
We can't just randomly reset variables based on their scope in this one
specific case. If we are going to "fix" this, it should be done by
introducing a way to do proper local scope variables. Resetting a
reference simply because it is convenient in this one case would be
completely inconsistent.-Rasmus
Rasmus,
it's not required to do anything like that and I myself would be against any
random resets,
but it's definitely not the case. There is nothing random and everything is
well determinted.
As I see the problem, it would be sufficient to fix the FOREACH and make it
working in the following way:
For example, say we have $a=array('apple', 'orange');
and iterate through $a values:
foreach($a as &$v) ...
as an initial step, $v MUST be assigned to the very first element of $a
which 'apple'. It should be done regadless of the
value that might be assigned to $v before (that's the first change)
On the next step, it will be advanced by one and assign $v to point to
'orange'
On the next iteration, it MUST also be advanced by one, reach the End Of the
Array, so it should assign NULL (or FALSE?) value to $v,
then finish the loop.
Isn't it what would work in a clearer way?
Evenmore, this change would make the foreach working more consistent with
each()/next()/prev() - they return FALSE as soon as internal pointer
reaches either boundary of the array. Neither stick with last element, like
foreach().
If you think current behaviour of foreach is useful, it's possible to
introduce new setting in php.ini, say strict_foreach=ON that will break
BC, but make foreach working clearer.
-jv
jvlad wrote:
"Rasmus Lerdorf" rasmus@lerdorf.com wrote in message
news:4B3785AC.2000507@lerdorf.com...We can't just randomly reset variables based on their scope in this one
specific case. If we are going to "fix" this, it should be done by
introducing a way to do proper local scope variables. Resetting a
reference simply because it is convenient in this one case would be
completely inconsistent.-Rasmus
Rasmus,
it's not required to do anything like that and I myself would be against any
random resets,
but it's definitely not the case. There is nothing random and everything is
well determinted.
As I see the problem, it would be sufficient to fix the FOREACH and make it
working in the following way:
For example, say we have $a=array('apple', 'orange');
and iterate through $a values:
foreach($a as &$v) ...
as an initial step, $v MUST be assigned to the very first element of $a
which 'apple'. It should be done regadless of the
value that might be assigned to $v before (that's the first change)
On the next step, it will be advanced by one and assign $v to point to
'orange'
On the next iteration, it MUST also be advanced by one, reach the End Of the
Array, so it should assignNULL(or FALSE?) value to $v,
then finish the loop.Isn't it what would work in a clearer way?
Evenmore, this change would make the foreach working more consistent with
each()/next()/prev() - they returnFALSEas soon as internal pointer
reaches either boundary of the array. Neither stick with last element, like
foreach().If you think current behaviour of foreach is useful, it's possible to
introduce new setting in php.ini, say strict_foreach=ON that will break
BC, but make foreach working clearer.
No chance. No .ini settings, and I still maintain it is inconsistent.
So, if I write this:
$a = array(1);
$b = 0;
$c = &$b;
$c = $a[0];
Would you agree that $b should be 1 at this point? If so, just because
I rewrite that code like this:
$a = array(1);
$b = 0;
$c = &$b;
foreach($a as $c);
Now you are arguing that $b should not be 1?
The two pieces of code are identical and since we do not have a block
scope and there is no syntax for explicitly indicating that $c is
somehow a different $c or that we should wipe out the $c that existed
before the foreach, I can see no sane reason to break the language for
this case.
And I don't see how your prev/next stuff has anything to do with this.
-Rasmus
No chance. No .ini settings, and I still maintain it is inconsistent.
So, if I write this:
$a = array(1);
$b = 0;
$c = &$b;
$c = $a[0];Would you agree that $b should be 1 at this point? If so, just because
I rewrite that code like this:$a = array(1);
$b = 0;
$c = &$b;
foreach($a as $c);Now you are arguing that $b should not be 1?
The two pieces of code are identical and since we do not have a block
scope and there is no syntax for explicitly indicating that $c is
somehow a different $c or that we should wipe out the $c that existed
before the foreach, I can see no sane reason to break the language for
this case.And I don't see how your prev/next stuff has anything to do with this.
-Rasmus
Rasmus,
$a = array(1);
$b = 0;
$c = &$b;
foreach($a as $c);
Now you are arguing that $b should not be 1?
The two pieces of code are identical
It's just a nightmare example. I wonder have you ever see anything like this
in real life?
Could you please let me see it too, for example in code.google.com?
If you cann't, what are you fighting for?
Interestingly, how many people will consider the code sample you
demonstrated ugly...
How many sporadic problems were already created and will be created just
beacause
of this unclear behavior of foreach?
And I don't see how your prev/next stuff has anything to do with this.
Ok. What my stuff has to do with this is there:
If prev/next were consistent with foreach, they would return first/last
element of the
array respectively as soon as they reached the boundary. But no! They return
FALSE.
Please have a look at this page
http://www.php.net/manual/en/control-structures.foreach.php
It's where you can find the following:
You may have noticed that the following are functionally identical:
<?php
$arr = array("one", "two", "three");
reset($arr);
while (list(, $value) = each($arr)) {
echo "Value: $value<br />\n";
}
foreach ($arr as $value) {
echo "Value: $value<br />\n";
}
?>
why not to make while (list(, &$value) = each($arr)) identical to foreach
($arr as &$value) ?
It would make the language more consistent.
Meanwhile I see that php core developers and Evangelist propose the way of
evolving difficulties.
For example, I used split() for many many years. Now it throws a warning and
it appears
that this function will be removed soon. I have to rewrite all my scripts
and replace
this function with pcreXXXX one and make sure that pcre extension is
built-in everywhere. So BC is
broken in an ugly and a very unpleasant way.
Many php developers who count on split() are simply ignored. Like me, they
have to
spend their time for monkey work. Nobody asked for such changes!
Difficulties are created in
a steady place.
On the other hand, people are experiencing difficulties with an important
function (php operator)
because it's behaviour is unclear/unexpected/nonintuitive. They all are
asking
for the change, but what? Right - they are ignored. Instead, new arguments
and ugly samples
will demonstrate us php developers that we are just fools and have plenty of
times.
Best regards,
JV
jvlad wrote:
$a = array(1);
$b = 0;
$c = &$b;
foreach($a as $c);
Now you are arguing that $b should not be 1?
The two pieces of code are identicalIt's just a nightmare example. I wonder have you ever see anything like this
in real life?
Could you please let me see it too, for example in code.google.com?
If you cann't, what are you fighting for?
Interestingly, how many people will consider the code sample you
demonstrated ugly...
How many sporadic problems were already created and will be created just
beacause
of this unclear behavior of foreach?
It isn't unclear. It is perfectly consistent. Whether it is ugly or
not is irrelevant.
And I don't see how your prev/next stuff has anything to do with this.
Ok. What my stuff has to do with this is there:
If prev/next were consistent with foreach, they would return first/last
element of the
array respectively as soon as they reached the boundary. But no! They return
FALSE.
Which has nothing to do with the question at hand here. We are talking
about breaking any reference in the variables used in the loop
construct. We are not talking about any other behaviour here.
-Rasmus
jvlad wrote:
$a = array(1);
$b = 0;
$c = &$b;
foreach($a as $c);
Now you are arguing that $b should not be 1?
The two pieces of code are identicalIt's just a nightmare example. I wonder have you ever see anything like
this
in real life?
Could you please let me see it too, for example in code.google.com?
If you cann't, what are you fighting for?
Interestingly, how many people will consider the code sample you
demonstrated ugly...
How many sporadic problems were already created and will be created just
beacause
of this unclear behavior of foreach?It isn't unclear. It is perfectly consistent. Whether it is ugly or
not is irrelevant.
Even though you can kill somebody using hammer, does it mean that it is
the feature to
be preserved in all future versions of the hammer?
Also, you didn't answer why another function that is WIDELY used, is going
to hell.
Why don't you defend its features which go to hell with this function? Why
don't you
defent the language BC in this case? What does make your position so
selective?
Why a useless and harmful (yes it's harmful according to so many posts)
feature is preserved
while uselfull and needed function is going away?
And I don't see how your prev/next stuff has anything to do with this.
Ok. What my stuff has to do with this is there:
If prev/next were consistent with foreach, they would return first/last
element of the
array respectively as soon as they reached the boundary. But no! They
return
FALSE.Which has nothing to do with the question at hand here. We are talking
about breaking any reference in the variables used in the loop
construct. We are not talking about any other behaviour here.
Please have a look at this page
http://www.php.net/manual/en/control-structures.foreach.php
It's where you can find the following:
You may have noticed that the following are functionally identical:
<?php
$arr = array("one", "two", "three");
reset($arr);
while (list(, $value) = each($arr)) {
echo "Value: $value<br />\n";
}
foreach ($arr as $value) {
echo "Value: $value<br />\n";
}
?>
I checked and it appears that they are not identical, quite the opposite,
they expose the
difference I mentioned before.
Each() assigns NULL to the value after the array pointer reached end.
ForEach() stays with last element in this case:
compare the output:
<?php
$arr = array("one", "two", "three");
reset($arr);
while (list(, $value) = each($arr)) {
echo "Value: $value<br />\n";
}
var_dump($value);
?>
<?php
$arr = array("one", "two", "three");
foreach ($arr as $value) {
echo "Value: $value<br />\n";
}
var_dump($value);
?>
-jv
jvlad wrote:
Meanwhile I see that php core developers and Evangelist propose the way of
evolving difficulties.
For example, I used split() for many many years. Now it throws a warning and
it appears
that this function will be removed soon. I have to rewrite all my scripts
and replace
this function with pcreXXXX one and make sure that pcre extension is
built-in everywhere. So BC is
broken in an ugly and a very unpleasant way.
Many php developers who count on split() are simply ignored. Like me, they
have to
spend their time for monkey work. Nobody asked for such changes!
Do you think we are deprecating split() just for fun? We are letting
you know that you need to start thinking about migrating your code away
from non-Unicode aware functions like ereg() and split(). The Web is
going entirely Unicode as is PHP 6 and these functions simply do not
support Unicode strings. preg_split() is a decent substitute and you
should be able to convert to it with only minor changes in your regex.
And this has nothing to do with this thread. Please keep your rants at
least somewhat on topic.
-Rasmus
Do you think we are deprecating split() just for fun?
Yes, exactly. It's just made for fun by core developers and brought
headache
to people developing in php.
We are letting you know that you need to start thinking about migrating
your code away from non-Unicode aware functions like ereg() and split().
Well, this filled up my php logs with some million records telling me this!
Do you think it's safer to keep thinking and have an opportunity to miss
anything
dangerous in the logs just becase they are flooded.
The Web is going entirely Unicode as is PHP 6 and these functions simply
do not
support Unicode strings.preg_split()is a decent substitute and you
should be able to convert to it with only minor changes in your regex.
If these changes are minor, why don't you provide a version of split for
php6 that will make them
on the fly? Why don't you consider the other scenarios that would maintain
the language BC?
And this has nothing to do with this thread. Please keep your rants at
least somewhat on topic.
It has direct relation to this thread because it's all about the policy of
the changes in the language.
Some pain changes are already done, some painless are not allowed.
Whould you please make your position more public and clearer?
-jv
Do you think we are deprecating split() just for fun?
Yes, exactly. It's just made for fun by core developers and brought
headache
to people developing in php.We are letting you know that you need to start thinking about migrating
your code away from non-Unicode aware functions like ereg() and split().Well, this filled up my php logs with some million records telling me this!
Do you think it's safer to keep thinking and have an opportunity to miss
anything
dangerous in the logs just becase they are flooded.The Web is going entirely Unicode as is PHP 6 and these functions simply
do not
support Unicode strings. preg_split() is a decent substitute and you
should be able to convert to it with only minor changes in your regex.If these changes are minor, why don't you provide a version of split for
php6 that will make them
on the fly? Why don't you consider the other scenarios that would maintain
the language BC?And this has nothing to do with this thread. Please keep your rants at
least somewhat on topic.It has direct relation to this thread because it's all about the policy of
the changes in the language.
Some pain changes are already done, some painless are not allowed.
Whould you please make your position more public and clearer?
as far as I see, the changes depends on how many work has to be done,
to preserve something.
posix functions like split, and so could have been modified to work
with the unicode strings, but nobody cared enough.
now this request is easier to leave this way, because this scenario
needs zero work against the proposed solutions.
but hey: patches are welcome!
:/
Tyrael
-jv
as far as I see, the changes depends on how many work has to be done,
to preserve something.
I see the same.
posix functions like split, and so could have been modified to work
with the unicode strings, but nobody cared enough.
Because this work is not in the TODO (milestones).
-jv
as far as I see, the changes depends on how many work has to be done,
to preserve something.I see the same.
posix functions like split, and so could have been modified to work
with the unicode strings, but nobody cared enough.Because this work is not in the TODO (milestones).
yeah, not anymore, but there was a thread about this on the internals
that (A. make the posix unicode-ready, B, use the preg extension for
the ereg functions transparently), but nobody cared enough.
The whole release of the 5.3 was a little bit mess.
There was a lot of feature, some of them wasn't ready for release, but
it was too much finished stuff to let this slide, and we are much
further from PHP6 than 5 years ago...
So its kinda funny, that some stuff had to die, because some stuff,
that wasnt even finished would be incompatible with.
Sorry for my english.
Tyrael
-jv
Do you think we are deprecating split() just for fun?
Yes, exactly. It's just made for fun by core developers and brought
headache
to people developing in php.We are letting you know that you need to start thinking about
migrating
your code away from non-Unicode aware functions like ereg() and
split().Well, this filled up my php logs with some million records telling
me this!
Do you think it's safer to keep thinking and have an opportunity to
miss
anything
dangerous in the logs just becase they are flooded.The Web is going entirely Unicode as is PHP 6 and these functions
simply
do not
support Unicode strings.preg_split()is a decent substitute and
you
should be able to convert to it with only minor changes in your
regex.If these changes are minor, why don't you provide a version of
split for
php6 that will make them
on the fly? Why don't you consider the other scenarios that would
maintain
the language BC?And this has nothing to do with this thread. Please keep your
rants at
least somewhat on topic.It has direct relation to this thread because it's all about the
policy of
the changes in the language.
Some pain changes are already done, some painless are not allowed.
Whould you please make your position more public and clearer?as far as I see, the changes depends on how many work has to be done,
to preserve something.
posix functions like split, and so could have been modified to work
with the unicode strings, but nobody cared enough.
Besides, nobody's forcing you to "upgrade" to php6. Pragmatism applied
I would just retrofit split() to preg_split() in userland whenever not
defined, since by right pcre cannot be disabled ;-)
now this request is easier to leave this way, because this scenario
needs zero work against the proposed solutions.but hey: patches are welcome!
:/Tyrael
-jv
On Mon, Dec 28, 2009 at 4:39 PM, Tjerk Meesters
tjerk.meesters@gmail.com wrote:
Do you think we are deprecating split() just for fun?
Yes, exactly. It's just made for fun by core developers and brought
headache
to people developing in php.We are letting you know that you need to start thinking about migrating
your code away from non-Unicode aware functions like ereg() and split().Well, this filled up my php logs with some million records telling me
this!
Do you think it's safer to keep thinking and have an opportunity to miss
anything
dangerous in the logs just becase they are flooded.The Web is going entirely Unicode as is PHP 6 and these functions simply
do not
support Unicode strings. preg_split() is a decent substitute and you
should be able to convert to it with only minor changes in your regex.If these changes are minor, why don't you provide a version of split for
php6 that will make them
on the fly? Why don't you consider the other scenarios that would
maintain
the language BC?And this has nothing to do with this thread. Please keep your rants at
least somewhat on topic.It has direct relation to this thread because it's all about the policy
of
the changes in the language.
Some pain changes are already done, some painless are not allowed.
Whould you please make your position more public and clearer?as far as I see, the changes depends on how many work has to be done,
to preserve something.
posix functions like split, and so could have been modified to work
with the unicode strings, but nobody cared enough.Besides, nobody's forcing you to "upgrade" to php6. Pragmatism applied I
would just retrofit split() topreg_split()in userland whenever not
defined, since by right pcre cannot be disabled ;-)
we are talking about php5.3. It got deprecated in that version, and
there were emails on the list about discontinuing the 5.2 branch as
soon as the 5.3 is ~stable.
Tyrael
now this request is easier to leave this way, because this scenario
needs zero work against the proposed solutions.but hey: patches are welcome!
:/Tyrael
-jv
We are letting you know that you need to start thinking about
migrating your code away from non-Unicode aware functions like
ereg() and split().Well, this filled up my php logs with some million records telling me
this! Do you think it's safer to keep thinking and have an opportunity
to miss anything dangerous in the logs just becase they are flooded.
Bitching about upgrading and things not working is not going to get you
any karma. We release release-candidates for a reason, and blindly
upgrading is unprofessional.
Derick
--
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
twitter: @derickr
We are letting you know that you need to start thinking about
migrating your code away from non-Unicode aware functions like
ereg() and split().Well, this filled up my php logs with some million records telling me
this! Do you think it's safer to keep thinking and have an opportunity
to miss anything dangerous in the logs just becase they are flooded.Bitching about upgrading and things not working is not going to get you
any karma. We release release-candidates for a reason, and blindly
upgrading is unprofessional.
Derick,
No need to upgrade.
If you write any line in php that other people are interested to run,
you'll see it soon, that different people use different versions of php.
If your code relies on split(), you'll get very good feedback from some of
them.
FYI: I didn't say anything like what you answered to.