Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46568
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain l-i-e.com designates 67.139.134.202 as permitted sender)
Message-ID: <3514.98.193.1262065698.squirrel@www.l-i-e.com>
In-Reply-To: <4B394CDC.9040709@warpmail.net>
References: <78.83.26502.F1DD83B4@pb1.pair.com> <4B38DDD3.8010108@hexon.cx>
    <A4.58.26502.869393B4@pb1.pair.com>
    <e666c3890912281520q632c4f0diecb804cab2605ee@mail.gmail.com>
    <4B394CDC.9040709@warpmail.net>
Date: Mon, 28 Dec 2009 23:48:18 -0600 (CST)
To: "Clint Priest" <cpriest@warpmail.net>
Cc: "Etienne Kneuss" <colder@php.net>,
 internals@lists.php.net
User-Agent: Hostbaby Webmail
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: [PHP-DEV] is_array on objects with ArrayAccess or Iterator 
     implementations
From: ceo@l-i-e.com ("Richard Lynch")

On Mon, December 28, 2009 6:27 pm, Clint Priest wrote:
> Etienne Kneuss wrote:
>> On Tue, Dec 29, 2009 at 12:04 AM, Clint Priest
>> <cpriest@warpmail.net> wrote:
>>> Unfortunately $x instanceOf ArrayAccess doesn't return true when $x
>>> is
>>> indeed an array.
>>
>> Making is_array return true for objects implementing ArrayAccess is
>> a
>> bad idea, for two main reasons:
>>
>> 1) is_array is a type check, and we should still be able to
>> distinguish real arrays from objects
> That's true of course, definitely would need to be able to
> distinguish.

is_array is precisely what we expect to be able to use to distinguish.

>> 2) ArrayAccess does not guarantee that an object will behave like an
>> array, (e.g. you won't be able to use sort() on an object
>> implementing
>> ArrayAccess.
> I wonder if this is something that users would be expecting, that any
> function which took an array would also take an object that implements
> certain interfaces (such as ArrayAccess and perhaps Countable).

Certainly if is_array returns TRUE, I would expect it to *be* an
array, and do what a PHP array is supposed to do. :-)

>> If, in your case, you want to accept both arrays and ArrayAccess
>> objects, I guess if (is_array($v) || $v instanceof ArrayAccess)  is
>> a
>> sufficiently good way to check.

A simple one-liner:
function is_arrayaccess ($object){
  return (is_array($object) || $object instanceof ArrayAccess);
}

and a global search and replace for is_array should not tax your
resources.

Another option is to have a class that implements ArrayAccess in the
simplest easiest way, by having a private property which is a true
is_array() built-in, and all the methods just work on that private
property.

You can pass that out from your library, and internally it can use the
array itself.  You may even find a combination of private/protected
that lets you expose the internal array when it is desirable to access
it directly.

> Would it be terribly difficult to make objects with ArrayAccess
> completely interchangable anywhere an array element would be required
> by
> a function?

Even if you could guarantee that every function would "work" it's
still a Bad Idea.

What are you going to do about var_dump and print_r?

Are they going to lie to me and tell me it's an array and print it out
exactly like an array?

Or is it going to distinguish, as it should?

No matter how much you love ArrayAccess, it's not an array.  It's a
class that implements specific array-like feature set.