[prev in list] [next in list] [prev in thread] [next in thread] 

List:       php-internals
Subject:    Re: [PHP-DEV] is_array on objects with ArrayAccess or Iterator
From:       Alexey Zakhlestin <indeyets () gmail ! com>
Date:       2009-12-31 9:35:04
Message-ID: cd5680a20912310135g1513268oc2df986869dd9485 () mail ! gmail ! com
[Download RAW message or body]

On Tue, Dec 29, 2009 at 3:01 AM, Etienne Kneuss <colder@php.net> wrote:
> Hi,
>
> On Tue, Dec 29, 2009 at 1:27 AM, Clint Priest <cpriest@warpmail.net> 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.
>>
>>> 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).
>>
>>> 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.
>>>
>>
>> I'm finding myself implementing ArrayAccess more and more often because its
>> so transparent to the consumer.  The reason this came up is because I was
>> considering returning all arrays from a certain section of my shared code
>> library always be an array object so that things like
>> $tblArray->pluck('Value') could be done, rather than array_pluck() type
>> functionality.
>>
>> That got me to thinking about all of the is_array() calls I would need to
>> replace throughout the codebase.
>>
>> Would it be terribly difficult to make objects with ArrayAccess completely
>> interchangable anywhere an array element would be required by a function?
>
> Yes, definitely, it would be a quite big amount of work (basically
> rewriting every functions dealing with arrays), and the interface that
> ArrayAccess proposes isn't enough for most array tasks.

can we go other way round and allow to use array's in ArrayAccess
context? I'd love to use it as a type-hint.


-- 
Alexey Zakhlestin
http://www.milkfarmsoft.com/
Sent from Prague, Czech Republic

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


[prev in list] [next in list] [prev in thread] [next in thread]