On Thu, Nov 6, 2008 at 22:06, Johannes Schlüter <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-11-06 at 10:10 -0800, Stanislav Malyshev wrote:
>> Hi!
>>
>> > So as suggested and wished, here is a patch that add a modifier '%' to
>> > 'a' in parameter parsing API, where it allows object that implements
>> > ArrayAccess to be accept. Although it doesn't invoke any their methods,
>> > i.e. just how it works nowdays.
>>
>> I think if you use HASH_OF then any object having get_properties should
>> be fine... Is there any reason to restrict it to ArrayAccess?
>
> This can be wrong/strange with classes implementing ArrayAccess (not
> ArrayObject) or Iterator.
>
> An example where one might expect an Iterator, reset() and next() use
> HASH_OF in 5.2:
>
> <?php
> class I implements Iterator {
> public $foo = "some real property";
>
> public function rewind() {
> echo __METHOD__, "\n";
> }
> public function current() {
> echo __METHOD__, "\n";
> return "from iterator";
> }
> public function valid() {
> static $continue = true;
>
> echo __METHOD__, "\n";
> if ($continue) {
> $continue = false;
> return true;
> } else {
> return false;
> }
> }
> public function next() {} public function key() {}
> }
>
> $i = new I;
>
> reset($i);
> echo current($i);
> ?>
> some real property
Whaaatheef...
I was going to reply back with the actual correct output when I
started wondering how exactly you got these results..
This is a total wtf and just cannot be the intended designed behaviour.
Switching it however "out-of-the-blue" and introducing the weirdest
and really hard-to-debug behaviour is pretty bad.
How many applications do rely on such behaviour though? The manual
clearly says these functions take arrays, not objects, so I can't
believe many do.
At most some legacy PHP4 applications which will never be upgraded to
PHP5 boxes would be my guess.
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php