FAQ
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?

Search Discussions

  • Jille Timmermans at Dec 28, 2009 at 4:33 pm

    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
  • Clint Priest at Dec 28, 2009 at 11:04 pm
    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:
    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
  • Etienne Kneuss at Dec 28, 2009 at 11:20 pm
    Hello,
    On Tue, Dec 29, 2009 at 12:04 AM, Clint Priest 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
    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:
    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
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    Etienne Kneuss
    http://www.colder.ch
  • Clint Priest at Dec 29, 2009 at 12:27 am

    Etienne Kneuss wrote:
    On Tue, Dec 29, 2009 at 12:04 AM, Clint Priest 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?
  • Etienne Kneuss at Dec 29, 2009 at 2:01 am
    Hi,
    On Tue, Dec 29, 2009 at 1:27 AM, 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.
    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.

    >



    --
    Etienne Kneuss
    http://www.colder.ch
  • Alexey Zakhlestin at Dec 31, 2009 at 9:35 am

    On Tue, Dec 29, 2009 at 3:01 AM, Etienne Kneuss wrote:
    Hi,
    On Tue, Dec 29, 2009 at 1:27 AM, 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.
    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
  • Richard Lynch at Dec 29, 2009 at 5:48 am

    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
    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.
  • Richard Lynch at Dec 29, 2009 at 5:37 am

    On Mon, December 28, 2009 10:30 am, Clint Priest wrote:
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedDec 28, '09 at 4:30p
activeDec 31, '09 at 9:35a
posts9
users5
websitephp.net

People

Translate

site design / logo © 2022 Grokbase