From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fed1rmmtao07.cox.net (fed1rmmtao07.cox.net [68.230.241.32]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j3O4Jnqe019588 for ; Sun, 24 Apr 2005 04:19:49 GMT Received: from eagle.creatures.lan ([68.98.17.33]) by fed1rmmtao07.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050424041941.BZGC1367.fed1rmmtao07.cox.net@eagle.creatures.lan> for ; Sun, 24 Apr 2005 00:19:41 -0400 Received: from [192.168.99.11] (cheetah.creatures.lan [192.168.99.11]) by eagle.creatures.lan (Postfix) with ESMTP id A13A827085 for ; Sat, 23 Apr 2005 21:51:43 -0700 (MST) Message-ID: <426B1FA9.50904@cox.net> Date: Sat, 23 Apr 2005 21:25:13 -0700 From: "D. Wokan" User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] PHP5 Unstable ? References: <30e61698050422051322736ee3@mail.gmail.com> <4268F474.20709@gentoo.org> <20050422170234.GA20015@tiger.gg3.net> <30e61698050422162655a28920@mail.gmail.com> <426A5D5D.5050901@flaska.net> In-Reply-To: <426A5D5D.5050901@flaska.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Archives-Salt: 4313d9e3-9d54-4e8e-8216-14ab7124a906 X-Archives-Hash: ca94a308835d518e9ddd64b5ee05db55 Jan Kundrát wrote: >Omer Cohen wrote: > > >>we're talking about one of the biggest OC communities. >> >> > > >...and the same community whose members write code like that described >in PHP's bug 31261 [1], which seems quite ugly, at least to me. > > >My point is that even if developers say their code is stable, it doesn't >have to mean it *really* is, altough they're probably correct. > >[1] http://bugs.php.net/bug.php?id=31261 > > > Actually, I can understand avoiding unnecessary bit flipping. I've done that in databases on occasion. I'll write a SQL statement that checks if there are matching records for an update instead of just executing a statement that makes changes to those matching records. Depending on the likelihood of changes and the number of records to be changed, it was sometimes faster to pre-qualify an update instead of just doing it when it wasn't going to find any matches. That's all the code in that particular bug does, check the value of a bit before turning it off. If it's already off, don't touch it. -- gentoo-dev@gentoo.org mailing list