Re: [PHP-DEV] Unsetting loop variables at the end of the loop
On Mon, Dec 28, 2009 at 4:39 PM, Tjerk Meesters wrote: > On 28-Dec-2009, at 20:39, Ferenc Kovacs wrote: > >> On Mon, Dec 28, 2009 at 11:58 AM, jvlad 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() to preg_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 >>> >>> >>> >>> -- >>> 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 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 Mon, Dec 28, 2009 at 4:07 PM, jvlad wrote: >> 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 > > > > -- > 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
On 28-Dec-2009, at 20:39, Ferenc Kovacs wrote: On Mon, Dec 28, 2009 at 11:58 AM, jvlad 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() 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 -- 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 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
> 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 -- 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 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. -- 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 Mon, 28 Dec 2009, jvlad wrote: > > 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 -- 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 Mon, Dec 28, 2009 at 11:58 AM, jvlad 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. 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 > > > > -- > 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
> 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 -- 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.
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:
\n";
}
foreach ($arr as $value) {
echo "Value: $value\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:
\n";
}
var_dump($value);
?>
\n";
}
var_dump($value);
?>
-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: > 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
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
>
> 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:
\n";
}
foreach ($arr as $value) {
echo "Value: $value\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:
> "Rasmus Lerdorf" 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] Unsetting loop variables at the end of the loop
"Rasmus Lerdorf" 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
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
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 wrote:
>> Adam Harvey wrote:
>>> 2009/12/27 Mike Wacker :
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 $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
On Sun, Dec 27, 2009 at 3:11 PM, Mike Wacker wrote:
> Adam Harvey wrote:
>>
>> 2009/12/27 Mike Wacker :
>>>
>>> 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 $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
Adam Harvey wrote:
2009/12/27 Mike Wacker :
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?)
--
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 : > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[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
