# is_array on objects with ArrayAccess or Iterator implementations

- Thread: https://externals.io/message/46559
- Original archive: https://news-web.php.net/php.internals/46559
- Started by Clint Priest on 2009-12-28T16:30:21+00:00
- Messages: 9
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #46559 — Clint Priest — 2009-12-28T16:30:21+00:00

URL: https://externals.io/message/46559#46559

Has there been any discussion or decision about whether `is_array()` 
should return true for objects which implement ArrayAccess or is there 
another function already available which checks for either being the case?

---

## #46560 — Jille Timmermans — 2009-12-28T16:33:23+00:00

URL: https://externals.io/message/46559#46560 · In reply to: #46559

Op 28-12-2009 17:30, Clint Priest schreef:
> Has there been any discussion or decision about whether `is_array()`
> should return true for objects which implement ArrayAccess or is there
> another function already available which checks for either being the case?
>
How about $x instanceOf ArrayAccess ?

-- Jille

---

## #46561 — Clint Priest — 2009-12-28T23:04:06+00:00

URL: https://externals.io/message/46559#46561 · In reply to: #46560

Unfortunately $x instanceOf ArrayAccess doesn't return true when $x is 
indeed an array.

Jille Timmermans wrote:
> Op 28-12-2009 17:30, Clint Priest schreef:
> > […]
> How about $x instanceOf ArrayAccess ?
> 
> -- Jille

---

## #46562 — Etienne Kneuss — 2009-12-28T23:20:32+00:00

URL: https://externals.io/message/46559#46562 · In reply to: #46561

Hello,


> 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
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.

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.

Best,

>
> Jille Timmermans wrote:
> > […]
>
> --
> 
> 
>
>



-- 
Etienne Kneuss
http://www.colder.ch

---

## #46564 — Clint Priest — 2009-12-29T00:27:08+00:00

URL: https://externals.io/message/46559#46564 · In reply to: #46562

Etienne Kneuss wrote:
> 
> > […]
> 
> 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?

---

## #46566 — Etienne Kneuss — 2009-12-29T02:01:23+00:00

URL: https://externals.io/message/46559#46566 · In reply to: #46564

Hi,


> Etienne Kneuss wrote:
> > […]
>
> That's true of course, definitely would need to be able to distinguish.
>
> > […]
>
> 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).
>
> > […]
>
> 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.

>



-- 
Etienne Kneuss
http://www.colder.ch

---

## #46567 — Richard Lynch — 2009-12-29T05:38:03+00:00

URL: https://externals.io/message/46559#46567 · In reply to: #46559

> Has there been any discussion or decision about whether `is_array()`
> should return true for objects which implement ArrayAccess or is there
> another function already available which checks for either being the
> case?

I really would prefer that is_array *not* return true unless something
really is a PHP array datatype.

I've had too much grief with psuedo-arrays from SimpleXML and/or SPL
or whatever it is that didn't quite implement *everything* an array
does, or didn't quite behave the way I expected with regards to
various functions.

Surely there can be some kind of is_a or instanceof or other operator
that would be more appropriate than overloading the built-in is_array
function.

-- 
Some people ask for gifts here.
I just want you to buy an Indie CD for yourself:
http://cdbaby.com/search/from/lynch

---

## #46568 — Richard Lynch — 2009-12-29T05:48:18+00:00

URL: https://externals.io/message/46559#46568 · In reply to: #46564

> Etienne Kneuss wrote:
> > […]
> 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.

> > […]
> 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. :-)

> > […]

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.

---

## #46580 — Alexey Zakhlestin — 2009-12-31T09:35:04+00:00

URL: https://externals.io/message/46559#46580 · In reply to: #46566

> Hi,
>
> 
> > […]
>
> 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