[PHP-DEV] Unsetting loop variables at the end of the loop
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). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unsetting loop variables at the end of the loop
2009/12/27 Mike Wacker mwac...@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-internalsm=125617546815934w=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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6's future
Chris Stockton wrote: Hello, On Mon, Nov 16, 2009 at 6:13 PM, Kalle Sommer Nielsen ka...@php.net wrote: But what is every ones input on the matter of attempting to boost PHP6's development? I'm willing to give my part in whatever I can to help getting up on the feet to get this ball rolling. I think that some more focus on PHP6 would be great! Though I am not sure if 5.2 could stop development (although perhaps a resource shift to 5.3/6, starving new 5.2 features/backports for 5.2 security/bug fixes only). I would hate to see PHP6 become P(erl)HP6 :p I have the same feeling on 5.2. While I'm very happy with PHP 5.3 (especially with the addition of closures), it takes a nontrivial amount of work to migrate a web app from PHP 5.2 to 5.3. The PHP 5.3 compatibility issue for the Drupal CMS (http://drupal.org/node/360605), for example, had over 200 comments, and it took about 9 months before a patch was committed to the current version of Drupal in September (see comment 158). That's not the only example, but it's a prominent one that comes to my mind. It makes sense to shift resources, but it's way too soon IMHO to stop doing security and bug fixes for 5.2. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unsetting loop variables at the end of the loop
Adam Harvey wrote:
2009/12/27 Mike Wacker mwac...@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-internalsm=125617546815934w=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?)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unsetting loop variables at the end of the loop
On Sun, Dec 27, 2009 at 3:11 PM, Mike Wacker mwac...@cornellsun.com wrote:
Adam Harvey wrote:
2009/12/27 Mike Wacker mwac...@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-internalsm=125617546815934w=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 $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?)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Are there zend classes hidden from php?
Hi! As some already know, I'm using the holidays to prepare a proposal for error handling in extensions (https://saintcyr.oeri.ch/trac/php-intl/wiki/ErrorHandling). Digging through many zend internals, I wonder if there is a possibility to use a common ancestor class without cluttering namespaces in php. Something like class CommonErrorThings; class ResourceBundle extends CommonErrorThings; class Collator extends CommonErrorThings; in which CommonErrorThings is invisible to PHP and ResourceBundle/Collator offered to the user. Any doc and/or example link would be greatly appreciated Happy Holidays HPO -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unsetting loop variables at the end of the loop
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:
On Sun, Dec 27, 2009 at 3:11 PM, Mike Wacker mwac...@cornellsun.com wrote:
Adam Harvey wrote:
2009/12/27 Mike Wacker mwac...@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-internalsm=125617546815934w=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 $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?)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unsetting loop variables at the end of the loop
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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Test OpenGrok installation (LXR replacement?)
Hi, Since LXR hasn't been updating since the shift to SVN, I've been investigating bringing it back. Today, though, I came across OpenGrok which appears to be a far more modern implementation of the same thing, using Lucene as the back end. I've set up a test installation of it at http://php-og.mgdm.net if anyone is interested in playing with it. Advantages seem to be: * It's really quite fast * It has a nicer UI, in my opinion * It's not too hard to set up * It handles multiple branches *relatively* well * It does incremental indexing, which I don't think LXR does It has the potential disadvantage that it requires Tomcat, which means running another web server somewhere, but I'm quite willing to volunteer to look after it if we can find a php.net machine to put it on at some point. For now, the test install is updating each branch from SVN and reindexing once every two hours. Any comments? Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Test OpenGrok installation (LXR replacement?)
hi, On Sun, Dec 27, 2009 at 10:17 PM, Michael Maclean mich...@no-surprises.co.uk wrote: Hi, Since LXR hasn't been updating since the shift to SVN, I've been investigating bringing it back. Today, though, I came across OpenGrok which appears to be a far more modern implementation of the same thing, using Lucene as the back end. I've set up a test installation of it at http://php-og.mgdm.net if anyone is interested in playing with it. Nice tool, thanks for the linktest site! Advantages seem to be: * It's really quite fast really fast :) * It has a nicer UI, in my opinion * It's not too hard to set up * It handles multiple branches *relatively* well * It does incremental indexing, which I don't think LXR does It has the potential disadvantage that it requires Tomcat, which means running another web server somewhere, but I'm quite willing to volunteer to look after it if we can find a php.net machine to put it on at some point. For now, the test install is updating each branch from SVN and reindexing once every two hours. Any comments? First suggestion, would it be possible to have *.c/h first in the results instead of the phpt? Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unsetting loop variables at the end of the loop
Rasmus Lerdorf ras...@lerdorf.com wrote in message
news:4b3785ac.2000...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unsetting loop variables at the end of the loop
jvlad wrote:
Rasmus Lerdorf ras...@lerdorf.com wrote in message
news:4b3785ac.2000...@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.
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Test OpenGrok installation (LXR replacement?)
On Dec 27, 2009, at 1:17 PM, Michael Maclean wrote: Hi, Since LXR hasn't been updating since the shift to SVN, I've been investigating bringing it back. Today, though, I came across OpenGrok which appears to be a far more modern implementation of the same thing, using Lucene as the back end. I've set up a test installation of it at http://php-og.mgdm.net if anyone is interested in playing with it. Advantages seem to be: * It's really quite fast * It has a nicer UI, in my opinion * It's not too hard to set up * It handles multiple branches *relatively* well * It does incremental indexing, which I don't think LXR does It has the potential disadvantage that it requires Tomcat, which means running another web server somewhere, but I'm quite willing to volunteer to look after it if we can find a php.net machine to put it on at some point. For now, the test install is updating each branch from SVN and reindexing once every two hours. Any comments? Looks great, and much nicer. If you feel pb11[1] could handle it, then we could dedicate this box to OpenGrok (as grok.php.net?). Regards, Philip [1] http://wiki.php.net/systems/pb11 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unsetting loop variables at the end of the loop
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: $valuebr /\n;
}
foreach ($arr as $value) {
echo Value: $valuebr /\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 pcre 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unsetting loop variables at the end of the loop
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 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? 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unsetting loop variables at the end of the loop
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 pcre 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
