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
