Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:82981 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 82681 invoked from network); 17 Feb 2015 16:26:02 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Feb 2015 16:26:02 -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:43808] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7D/D2-19463-79B63E45 for ; Tue, 17 Feb 2015 11:26:00 -0500 Received: (qmail 14849 invoked by uid 89); 17 Feb 2015 16:25:56 -0000 Received: by simscan 1.3.1 ppid: 14843, pid: 14846, t: 0.0816s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@86.189.147.37) by mail4.serversure.net with ESMTPA; 17 Feb 2015 16:25:56 -0000 Message-ID: <54E36B94.1080103@lsces.co.uk> Date: Tue, 17 Feb 2015 16:25:56 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: internals@lists.php.net References: <011801d04a07$83ab1c00$8b015400$@php.net> <016f01d04a3a$e9183220$bb489660$@php.net> <022801d04ab1$4a0c47d0$de24d770$@php.net> <1913e09d7f52541901d8574d2080a63f@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Reviving scalar type hints From: lester@lsces.co.uk (Lester Caine) On 17/02/15 15:47, Anthony Ferrara wrote: > A static analyzer (one of the reasons people want strict) would error > there. The reason is that *at compile time* it can't reason about the > code well enough to determine if there's an error or not. You're > passing a string where you expect an int. Is that going to work? We > don't know. So the analyzer would need to throw a warning that the > cast is potentially unsafe because it can't guarantee that the runtime > won't throw an error. Which means that to remove the warning you'd > need to add an explicit cast. This is what I do not get ... I have no idea what string will be provided, so either we get a valid number or we don't. Conversion of the string to a number needs to follow several rules such as thousand divider or decimal point, or perhaps even spelt out numbers. If the input string can't be converted to a number then we need the error message - explicit casting fixed nothing - you can't eliminate the error if the passed string can't be converted so you need an alternate escape route. A generic 'type fault' does not help since you want to return the fault to the inputting source? Static analysis only works if you assume there is no human involvement in the generation of the inputs? Now if you are handling the problem of mistakes in the input prior to the function call you already know that the data is good so why do you need 'strict' at all. You will process the string, decide if you want to tell the client that it must be a whole number, or if it exceeds some limit. That may even be done in javascript in the browser, so what is fed back has already been sanitised. It will come in as a string and you know it is a valid number ... -- 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