Re: array_key_exists BC break

On Thu, Nov 6, 2008 at 22:06, Johannes Schlüter <johannes@php.net> 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