Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:75930 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 88171 invoked from network); 23 Jul 2014 08:49:34 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Jul 2014 08:49:34 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.214 mail4-2.serversure.net Linux 2.6 Received: from [217.147.176.214] ([217.147.176.214:55475] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4A/D1-21666-D177FC35 for ; Wed, 23 Jul 2014 04:49:34 -0400 Received: (qmail 17655 invoked by uid 89); 23 Jul 2014 08:49:32 -0000 Received: by simscan 1.3.1 ppid: 17648, pid: 17652, t: 0.0664s scanners: attach: 1.3.1 clamav: 0.96/m:52 Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 23 Jul 2014 08:49:32 -0000 Message-ID: <53CF771B.2080603@lsces.co.uk> Date: Wed, 23 Jul 2014 09:49:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "internals@lists.php.net >> PHP internals" References: <53CF6C1A.1020208@lsces.co.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] phpng - loss of IS_BOOL From: lester@lsces.co.uk (Lester Caine) On 23/07/14 09:12, Laruence wrote: > On Wed, Jul 23, 2014 at 4:02 PM, Lester Caine wrote: >> > I'm trying to work through some of the more subtle changes in phpng and >> > one that sticks out is the loss of IS_BOOL. I think the explanation is >> > that it removes a read, but while I'm only seeing a few uses of is_bool >> > across the codebase, every one of them is used simply to convert the >> > bool value into some other format. Surely what would make more sense >> > here is simply to make the type_flag either true or false, and retain >> > the IS_BOOL as a single identifiable type? Having two types both >> > indicating 'bool' just seems wrong. > there is a _IS_BOOL macro to identifiable bool type.. > you can use it in your own codes. But THAT has to look for two types ... When the 'object' is simply 'bool' I'm looking for the explanation as to why it HAS to change rather than anything else. I can see that using the 64bit value field is overkill, but there is still plenty of spare space in the TYPE element to not have to create an extra object type? The two types of boolean just need a different type_flags entry? THEN is_false and is_true make sense as macro's of is_bool ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk