Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:18962 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 51546 invoked by uid 1010); 15 Sep 2005 11:53:51 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 51531 invoked from network); 15 Sep 2005 11:53:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Sep 2005 11:53:51 -0000 X-Host-Fingerprint: 203.41.13.159 unknown Received: from ([203.41.13.159:22759] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 9D/D0-41173-FC069234 for ; Thu, 15 Sep 2005 07:53:51 -0400 Message-ID: <9D.D0.41173.FC069234@pb1.pair.com> To: internals@lists.php.net Date: Thu, 15 Sep 2005 21:53:45 +1000 User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <43276022.6020702@encode.net.au> <7C.1C.41173.4D828234@pb1.pair.com> <63.BA.41173.BB6E8234@pb1.pair.com> <4328EFC1.3030500@lerdorf.com> <38.3D.41173.B58F8234@pb1.pair.com> <4328F9DC.40302@lerdorf.com> <4329550B.90303@lerdorf.com> In-Reply-To: <4329550B.90303@lerdorf.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 203.41.13.159 Subject: Re: [PHP-DEV] Reference handling change and PHP 4.4.0 From: leigh@eon.com.au (Leigh Makewell) Rasmus Lerdorf wrote: > That's fine, and you shouldn't care, I agree. I argued much the same > point just yesterday in a chat with Ilia. You do however seem to be > glossing over the fact that this new check can be very helpful. Take > this case: > > sort(array(3,2,1)); > > Or any other example where the function in question has no other purpose > than to modify its argument. When you pass in something to a function > like this which has no permanent storage, chances are pretty high that > this is a bug in the code and you probably want to know about that. So > I really don't see this as such a black and white case. I am all for > making this a non-fatal error in all cases to allow scripts to keep > working, but I don't buy the argument that just because we didn't check > for this before we are not allowed to check for it now when it can find > valid bugs like this. > > -Rasmus No you don't understand me. While I disagree with the way the bug was solved, and the inconsistancies it seems to introduce, I don't have a problem with the error message in PHP5. PHP4 however should be stable and unchanging except for bug fixes, and maybe additions, never removals. Scripts that worked error free before on 4.3 are now spewing them out in 4.4. I don't believe programmers should have to deal with that sort of problem unless they make a major version upgrade. Anyway, this is getting way off from my original post which was a critisism of the handling of this whole situation and the treatment of the community. I don't feel I am qualified to argue this particular issue because I have never encountered it. I don't use references unless I absolutely have to. I believe all of this could of been avoided with careful PR. Now you need some major PR to repair the damage. Leigh :)