Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46534
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.211.202 cause and error)
Message-ID: <4B38106C.2080806@lerdorf.com>
Date: Sun, 27 Dec 2009 17:57:00 -0800
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: jvlad <dmda@yandex.ru>
CC: internals@lists.php.net
References: <31.35.26502.C79573B4@pb1.pair.com>	 <e50d0a480912270517i44c4b3d0o4787e65e2cfc7f25@mail.gmail.com>	 <1B.86.26502.42B673B4@pb1.pair.com> <b54d0abe0912270801o6bb39a01x63ceecaf23701660@mail.gmail.com> <4B3785AC.2000507@lerdorf.com> <8A.91.26502.CDB083B4@pb1.pair.com>
In-Reply-To: <8A.91.26502.CDB083B4@pb1.pair.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Unsetting loop variables at the end of the loop
From: rasmus@lerdorf.com (Rasmus Lerdorf)

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 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