Hello Terje, sorry i often only remember the outcome.
best regards marcus Wednesday, September 13, 2006, 9:52:57 AM, you wrote: > 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: >> >> > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
