# Making ArrayAccess objects more array-like? - Thread: https://externals.io/message/25648 - Original archive: https://news-web.php.net/php.internals/25648 - Started by tslettebo@broadpark.no on 2006-09-13T06:39:57+00:00 - Messages: 4 - 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 --- ## #25648 — tslettebo@broadpark.no — 2006-09-13T06:39:57+00:00 URL: https://externals.io/message/25648#25648 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...? --- ## #25649 — Marcus Boerger — 2006-09-13T07:30:35+00:00 URL: https://externals.io/message/25648#25649 · In reply to: #25648 Hello Terje, long ago we decided against supporting it in the array functions. best regards marcus Wednesday, September 13, 2006, 8:39:57 AM, you wrote: > 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...? Best regards, Marcus --- ## #25660 — tslettebo@broadpark.no — 2006-09-13T07:52:57+00:00 URL: https://externals.io/message/25648#25660 · In reply to: #25649 Hi Marcus. > long ago we decided against supporting it in the array functions. Ok, thanks. Could I ask what the reasons were (Alternatively get a pointer to the discussion)? Regards, Terje > best regards > marcus > > Wednesday, September 13, 2006, 8:39:57 AM, you wrote: > > > […] > > > […] one) > > […] However, > > […] `count()`, > > […] > > > […] call > > […] > > > […] > > > […] leads to > > […] code. > > > […] object > > […] very > > […] passed). > > […] > > > […] there > > […] code > > […] as > > […] built-in > > […] > > > […] > > > […] > > > […] I'm > > […] development > > […] --- ## #25676 — Marcus Boerger — 2006-09-13T22:12:52+00:00 URL: https://externals.io/message/25648#25676 · In reply to: #25660 Hello Terje, sorry i often only remember the outcome. best regards marcus Wednesday, September 13, 2006, 9:52:57 AM, you wrote: > Hi Marcus. > > […] > Ok, thanks. Could I ask what the reasons were (Alternatively get a pointer > to the discussion)? > Regards, > Terje > > […] > one) > > […] > However, > > […] > `count()`, > > […] > call > > […] > leads to > > […] > code. > > […] > object > > […] > very > > […] > passed). > > […] > there > > […] > code > > […] > as > > […] > built-in > > […] > I'm > > […] > development > > […] Best regards, Marcus