Hi all. (Again, I've searched the archives, but haven't found anything on this one) The ArrayAccess interface allows one to essentially overload the index operator "[]" [1], which is nice, as it makes it possible to implement things like type-checked associative arrays, variants, tuples, etc. However, you can't use it with any of the built-in array functions (such as count(), or the array_*-functions), which means you have to either:
1. Have something like an "as_array()" member function, returning a reference to the embedded array, and call this every time you need to call one of these functions, or: 2. Implement the functions as member functions on the object. Both of these solutions are rather inelegant, and in particular, 2. leads to unnecessary code bloat, and both gives a different calling convention compared to ordinary arrays, which can surely confuse readers of the code. My question is: Has it been considered changing the standard library functions that take an array as a parameter, to be able to take an object implementing ArrayAccess/IteratorAggregate, also? Would it perhaps be a very large change? That would be understandable, given that it could mean the library having to be able to call into user code (the object being passed). However, this is done elsewhere, too, such as foreach(). I know the inability to return a reference is well known. However, has there come to a consensus about how to solve it (or if)? It tends to trip up code using these "arrays" a lot... Sometimes, you get no change in the array, as it turns out it operated on a copy of an element, rather than the built-in array. Regards, Terje [1] Since ArrayAccess essentially means overloading the index operator, I'm wondering how this have gone through, since some members of the development team (Andi?) appears to have very strong feelings against operator overloading...? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
