Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83911 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 47030 invoked from network); 26 Feb 2015 18:02:04 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Feb 2015 18:02:04 -0000 Authentication-Results: pb1.pair.com smtp.mail=theodorejb@outlook.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=theodorejb@outlook.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain outlook.com designates 65.54.190.224 as permitted sender) X-PHP-List-Original-Sender: theodorejb@outlook.com X-Host-Fingerprint: 65.54.190.224 bay004-omc4s22.hotmail.com Received: from [65.54.190.224] ([65.54.190.224:62050] helo=BAY004-OMC4S22.hotmail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 52/19-32582-99F5FE45 for ; Thu, 26 Feb 2015 13:02:03 -0500 Received: from BAY178-W44 ([65.54.190.199]) by BAY004-OMC4S22.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 26 Feb 2015 10:01:59 -0800 X-TMN: [726p9q33SdUYycPWRveWAQFnSU9KFk+x] X-Originating-Email: [theodorejb@outlook.com] Message-ID: To: "francois@php.net" , "internals@lists.php.net" Date: Thu, 26 Feb 2015 12:01:58 -0600 Importance: Normal In-Reply-To: <0a7a01d051de$12e68070$38b38150$@php.net> References: ,<0a7a01d051de$12e68070$38b38150$@php.net> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Feb 2015 18:01:59.0008 (UTC) FILETIME=[5099FE00:01D051EE] Subject: RE: [PHP-DEV] A different user perspective on scalar type declarations From: theodorejb@outlook.com (Theodore Brown) Hi Fran=E7ois=2C=0A= =0A= > Instead of rejecting the whole RFC=2C you can ask to keep supporting lead= ing=0A= > and trailing blanks in numeric strings. That's something that is really= =0A= > still under discussion=2C even between authors. To be clear=2C I prefer= =0A= > authorizing leading and trailing blanks (but just blanks)=2C Zeev prefers= =0A= > restricting it=2C and I am not sure about Dmitry's preference. So you see= it=0A= > is still open !=0A= =0A= I can definitely understand the indecision here! On the one hand=2C support= ing=0A= leading/trailing spaces usually works great when working with user input (a= nd=0A= many applications depend on this). On the other hand=2C it can lead to bugs= =0A= in sensitive code (e.g. for authentication=2C finance=2C or cryptography). = This=0A= is where the dual-mode RFC has a clear advantage=2C in my view. Its default= =0A= weak mode doesn't break BC and "just works" for user input=2C and developer= s=0A= can optionally enable strict mode for a file when needed.=0A= =0A= > About BC=2C I don't think we are too lax with BC because developers would= have=0A= > years to fix a pair of lines in their code. Running wordpress and other= =0A= > large code just found 10 or 20 places where developers would have to chan= ge=0A= > something. So that's really minimal work and they have long years to do i= t.=0A= =0A= The work to properly trim and validate input is not necessarily minimal=2C= =0A= unless developers add explicit casts wherever input is passed to a function= =0A= expecting a integer or float (in which case the advantage of the stricter= =0A= rules is lost). From my own experience working with legacy codebases=2C I= =0A= think you are underestimating the amount of work required to avoid errors= =0A= caused by a change to PHP's default casting behavior.=0A= =0A= > Our STH does not break anything. Maybe the newly-published version is mor= e=0A= > clear. We propose implementing *exactly* the PHP5 logic and just raise=0A= > E_DEPRECATED messages that won't stop execution at all. Ignoring these=0A= > messages=2C there will be absolutely no difference in behavior with PHP 5= .=0A= =0A= I understand the two-staged migration proposed in the RFC. It most certainl= y=0A= will break things in a future version. Essentially the coercive proposal=0A= forces developers to update large amounts of legacy code dependent on PHP's= =0A= existing=2C well-documented behavior.=0A= =0A= > Maybe not clear in the RFC but return types are handled exactly the same= =0A= > way.=0A= =0A= Thanks for clarifying. I think this behavior should be mentioned in the=0A= coercive RFC along with usage examples.=0A= =0A= >> Strict types + static analysis can tell you that this will fail (because= it's=0A= >> based purely on types=2C and a string is being passed to a function expe= cting=0A= >> an integer). Coercive typing cannot statically tell you that it will fai= l=2C=0A= >> because it doesn't know whether the string passed to `getInvoiceByCustom= er`=0A= >> is acceptable as an integer without also knowing its value.=0A= >=0A= > Agreed. That's why=2C in the future=2C we may add new 'strict' type hint = that=0A= > will accept nothing but their native type. We didn't add them here becaus= e=0A= > it would have been too confusing for a first release=2C and the whole=0A= > discussion is already complex enough. But I agree they can have some use.= =0A= ...=0A= > If strict type hints are defined in the future=2C and if you use them in = your=0A= > example=2C you will get exactly the same and static analysis will still b= e=0A= > able to find your bug. The difference is that you will decide to use them= =0A= > only where you need to make it more strict=2C function by function=2C arg= ument=0A= > by argument.=0A= =0A= It sounds like you recognize the benefits of an optional strict mode. But = =0A= implementing this via separate 'strict' type hints would be far worse than= =0A= the per-file declare switch=2C in my opinion. Rather than only needing to t= hink=0A= about function calls and returns *in the current file=2C* a user would have= to=0A= think about which kind of type hint is used on individual functions and eve= n=0A= individual arguments in every other file or library they want to use. Moreo= ver=2C=0A= libraries would not be able to add these strict hints without breaking BC.= =0A= =0A= Why wait for a disparate strict mode in a future version of PHP=2C when the= re=0A= is already a practical proposal on the table which can make it into PHP 7?= =0A= =0A= Best regards=2C=0A= =0A= Theodore Brown=0A= =