Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25676
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain php.net from 81.169.182.136 cause and error)
Date: Thu, 14 Sep 2006 00:12:52 +0200
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <75351270.20060914001252@marcus-boerger.de>
To: =?iso-8859-1?Q?Terje_Sletteb=F8?= <tslettebo@broadpark.no>
Cc: internals@lists.php.net
In-Reply-To: <0ccc01c6d709$a18eb6c0$a900000a@adstate.local>
References: <03ab01c6d6ff$6e38ab50$9a02a8c0@pc> <1985468657.20060913093035@marcus-boerger.de> <0ccc01c6d709$a18eb6c0$a900000a@adstate.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Making ArrayAccess objects more array-like?
From: helly@php.net (Marcus Boerger)

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