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.
Ilia
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 beNULL
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
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 beNULL
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 forkey()
[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 ofkey()
/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