Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:24678 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 57272 invoked by uid 1010); 19 Jul 2006 13:56:21 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 57256 invoked from network); 19 Jul 2006 13:56:21 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Jul 2006 13:56:21 -0000 X-Host-Fingerprint: 217.79.190.163 r163.red.fastwebserver.de Received: from ([217.79.190.163:13299] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.3 r(11751M)) with ESMTP id DA/66-11992-30A3EB44 for ; Wed, 19 Jul 2006 09:56:20 -0400 To: internals@lists.php.net,christian.stocker@bitflux.ch (Christian Stocker) Date: Wed, 19 Jul 2006 15:56:15 +0200 Message-ID: <20060719155615.35eff909@pierre-u64> In-Reply-To: <44BE347A.5060106@bitflux.ch> References: <44BE2AE5.4090700@bitflux.ch> <10845a340607190624w44b6d7b1ycff7610d03cc3676@mail.gmail.com> <44BE347A.5060106@bitflux.ch> Reply-To: pierre.php@gmail.com X-Newsreader: Sylpheed-Claws 2.1.1 (GTK+ 2.8.18; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Posted-By: 217.79.190.163 Subject: Re: [PHP-DEV] PHP 5.2-dev "Cannot use array returned from foo::__get('bar') in write context" From: pierre.php@gmail.com (Pierre) On Wed, 19 Jul 2006 15:32:42 +0200 christian.stocker@bitflux.ch (Christian Stocker) wrote: > > > On 19.7.2006 15:24 Uhr, Richard Quadling wrote: > > For PHP 5.2.0-dev (cli) (built: Jul 12 2006 12:20:25), I get ... > > > > Fatal error: Cannot use array returned from foo::__get('bar') in > > write context in C:\- on line 16 > > > > But only once, not 1 per line. > > > > $f = new foo(); > > $a = $f->bar; > > foreach($a as $key => $value) > > > > fixes the code. > > > > I know (forgot to mention it), but still annoying as I have to fix a > lot of lines to do that. > > If there are technical reasons for the fatal error, fine, I have to > live with it then. If there is good reasons for this change, it should be a good candidate for E_STRICT but not E_FATAL/RECOVERABLE. We should also have a notice in the upgrading notes. I can do it as soon as we agreed on a solution. -- Pierre