Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:48107
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.215 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc:content-type;
        b=REwbWgY9rL1wfIAWmObDDONjVWsy+FcdZMYc+S4aAtfoUonRQFzLfEi39kTaLHzFcp
         uakoj9BnjFLTXd/SBQItkL5HAB45Qci0C6SeUvVdAsxvS7M5o8thbeUeYgPEMBr4fbYI
         5eLeyQAlgY4HkeNPcVtyiQ7o3M1GMn6VDsEFA=
MIME-Version: 1.0
In-Reply-To: <i2yd3ada2bf1004270151ra176f160zcc9451019ea1f59d@mail.gmail.com>
References: <m2re666c3891004270117j42114dbbmb819a72949fef88b@mail.gmail.com> 
	<i2yd3ada2bf1004270151ra176f160zcc9451019ea1f59d@mail.gmail.com>
Date: Tue, 27 Apr 2010 11:13:40 +0200
Message-ID: <t2za5bff9dd1004270213g71a40c4ai1f9284dca0411090@mail.gmail.com>
To: Peter Cowburn <petercowburn@gmail.com>
Cc: Etienne Kneuss <colder@php.net>, internals Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] ArrayAccess::offsetGet not returning a ref
From: daniel.egeberg@gmail.com (Daniel Egeberg)

On Tue, Apr 27, 2010 at 10:51, Peter Cowburn <petercowburn@gmail.com> wrote:
> On 27 April 2010 09:17, Etienne Kneuss <colder@php.net> wrote:
>> Hi,
>>
>> it looks like the fact that ArrayAccess::offsetGet is not returning a
>> reference is a recurrent problem, I see basically 4 options:
>>
>> a) Ignore the issue, change nothing
>>
>> b) Rewrite offsetGet to return a ref, breaking BC
> -1,000,000
>>
>> c) Create a new ArrayAccess interface where it does return a ref
>>
>> d) Relax prototype checks so that both are allowed.
>
> Of the options presented, I think d) would be the best of the bunch.
> Folks seem to expect the ability to get references so any solution
> that gives them that would be better IMO than keeping the interface
> as-is.

Without having the technical insight in how it works internally, I
would also say that from an end-user perspective, option (d) makes
most sense.

>>
>> Personally, I believe that a fatal on such prototypes error is not
>> warranted, so I'd prefer (d).
>>
>> What do you think would be the best option? Can you think of another?

-- 
Daniel Egeberg