Making ArrayAccess objects more array-like?

19 years ago by tslettebo@broadpark.no — view source — reply

unread

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:

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:
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...?

19 years ago by Marcus Boerger — view source — reply

unread

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:

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:

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

19 years ago by tslettebo@broadpark.no — view source — reply

unread

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:

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:

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

19 years ago by Marcus Boerger — view source — reply

unread

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:

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:

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