Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83892 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 92302 invoked from network); 26 Feb 2015 12:28:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Feb 2015 12:28:00 -0000 Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; 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:40583] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 79/D4-65287-E411FE45 for ; Thu, 26 Feb 2015 07:27:59 -0500 Received: (qmail 13155 invoked by uid 89); 26 Feb 2015 12:27:56 -0000 Received: by simscan 1.3.1 ppid: 13142, pid: 13152, t: 0.0766s 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; 26 Feb 2015 12:27:55 -0000 Message-ID: <54EF114B.3080300@lsces.co.uk> Date: Thu, 26 Feb 2015 12:27:55 +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: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Strict typing and callback vs declare() From: lester@lsces.co.uk (Lester Caine) On 26/02/15 11:34, Benjamin Eberlei wrote: >> You 'll have to think about each file anyway. To add or not to add >> > declare(strict_types=1). >> > > Yes, but It has only exactly one ruleset to keep in mind. With your > approach the ruleset space is infinite. Much more complex. Currently the rule set is already 'infinite' since many libraries will already be checking for their own conditions and verifying they have a valid variable to start with is the first step. The nice thing about PHP *IS* it's flexibility in the way one is not constrained by a single core framework and the more I look at this, the more making PHP a little more flexible makes sense. Being able to bolt in a validation system appropriate to the library being used makes perfect sense, but I already see that code in the libraries I use anyway. The problem with proper validation is that it either needs the annotation RFC to allow definition of all the rules or access to some other data model such as the metadata of a database. Simply saying 'int' and then blocking all valid forms of that value is only part of the process but providing a mechanism that CAN be optimised for the target and which can be enhanced via that target can only be an improvement on what is proposed so far. And the title here is wrong - this is not restricted to 'strict' it applies to all scalar type hinting/checking. -- 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