Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:8878
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <5.1.0.14.2.20040401223040.021a6ef8@127.0.0.1>
Date: Thu, 01 Apr 2004 22:34:17 +0200
To: Marcus Boerger <helly@php.net>,Ilia Alshanetsky <ilia@prohost.org>
Cc: internals@lists.php.net
In-Reply-To: <15963916843.20040401215650@marcus-boerger.de>
References: <200404011424.25416.ilia@prohost.org>
 <200404011424.25416.ilia@prohost.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] Bug #27782
From: andi@zend.com (Andi Gutmans)

I'm not sure these functions should be fixed. Personally I always recommend 
to people to use foreach() or sometimes each() but never these old 
functions. If the only problem is that once we reach the end, we can't call 
prev() then I think we should just document this. Using array_valid() in 
conjunction with the shorter next(), prev(), current() might look a bit odd 
but it's something we could do. The question is if it's really worth it.


At 09:56 PM 4/1/2004 +0200, Marcus Boerger wrote:
>Hello Ilia,
>
>Thursday, April 1, 2004, 9:24:25 PM, you wrote:
>
> > This bug is the result of the engine moving the current array position 
> to 0x0
> > if there are no more next elements (next/each) or no more preceding 
> elements
> > (prev). The results is that if you were to run:
> > <?php
> > $a = array(1,2,3);
> > while(next($a));
> > echo prev($a);
>?>>
> > the out would be NULL rather then 2. The fix that I just reverted from PHP4
> > addresses this problem for the 3 functions involved, but has a BC issue.
> > Before the patch since the array position was pointing to 0x0 functions 
> like
> > key() that depend on the position would return FALSE/NULL, now they end up
> > returning the first or last element depending on wether next or prev 
> was used
> > to iterate through the array. This is why I decided to revert the patch for
> > 4.3.X.
> > For PHP 5 we need to decide wether we want to keep the patch with the 
> changes
> > it introduces. Revert it and assume the old behavior as correct or to add a
> > flag/option that would detect this condition. Allowing the old 
> functionality
> > to be maintained but also make it possible to allow the example above 
> to work
> > correctly.
>
>Sidenote: A while back i wanted to have array_has_more() which would now
>be array_valid() or just valid().
>
>Without that mentioned test we depend on key(@eof) -> false|NULL because
>next(@eof) -> false|NULL has the sideeffect that it either must be
>disallowed to store false|NULL or that it simply won't work. The patch
>drops the necessary behavior for key() [now disallow storing false|NULL?].
>
>Generally i would like to have the same set of functions available for
>arrays we have for iterators. That would add valid(). When we have this
>we could also adapt the logic most people would implement - access after
>last elemet [when valid()===false] leads to undefined - in other words
>the behavior of key()/next() is irrelevant.
>
>Test script:
>$ php -r 
>'$a=array(1,2);var_dump($a);var_dump(key($a));var_dump(next($a));var_dump(key($a));var_dump(next($a));var_dump(key($a));'
>array(2) {
>   [0]=>
>   int(1)
>   [1]=>
>   int(2)
>}
>int(0)          // key(@0)
>int(2)          // next(@0)
>int(1)          // key(@1)
>bool(false)     // next(@1)
>int(1)          // key(@eof)  we need retval false|NULL or we need valid()
>
>regards
>marcus
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php