Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41741
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.198.239 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:cc:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=MgCIfFSNbfPfPg+SUZ6jdNaoBry1ShgGbtheN90fWwq192OI3VHO8mtO1t4eguC/jZ
         CpgfvmCY2YWLkg6IS8OaZZGr84wugVopJ/Y6npyLNBy+4MSvNiyW8Np3rG/M4tLSLOfY
         jcMb2LJnKI14sJ02J+aVqk3xMQLSgnZyr4nFM=
Message-ID: <7f3ed2c30811061324o663e4809p8e631d67656ec91@mail.gmail.com>
Date: Thu, 6 Nov 2008 22:24:58 +0100
To: "=?ISO-8859-1?Q?Johannes_Schl=FCter?=" <johannes@php.net>
Cc: "Stanislav Malyshev" <stas@zend.com>, "Felipe Pena" <felipensp@gmail.com>, 
	"Geoffrey Sneddon" <foolistbar@googlemail.com>, 
	"Lukas Kahwe Smith" <mls@pooteeweet.org>, 
	"PHP Internals" <internals@lists.php.net>
In-Reply-To: <1226005570.4679.12.camel@goldfinger.johannes.nop>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <4900DB81.4000805@zend.com> <490609A1.7090400@gravitonic.com>
	 <1225199800.878.0.camel@localhost>
	 <3F3445975B55414BB4A214B32E178657@pc>
	 <4A4FE9BC-F000-4AEE-A68C-8EFEA9DCD154@pooteeweet.org>
	 <4910D3E5.4020406@zend.com>
	 <237D5067-10C6-4D25-8CCF-FEF9FE44F6F6@googlemail.com>
	 <1225973406.5465.18.camel@felipe> <49133302.4040701@zend.com>
	 <1226005570.4679.12.camel@goldfinger.johannes.nop>
Subject: Re: [PHP-DEV] array_key_exists BC break
From: hannes.magnusson@gmail.com ("Hannes Magnusson")

On Thu, Nov 6, 2008 at 22:06, Johannes Schl=FCter <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 =3D "some real property";
>
>    public function rewind() {
>        echo __METHOD__, "\n";
>    }
>    public function current() {
>        echo __METHOD__, "\n";
>        return "from iterator";
>    }
>    public function valid() {
>        static $continue =3D true;
>
>        echo __METHOD__, "\n";
>        if ($continue) {
>            $continue =3D false;
>            return true;
>        } else {
>            return false;
>        }
>    }
>    public function next() {} public function key() {}
> }
>
> $i =3D 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