Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:75612 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 59836 invoked from network); 16 Jul 2014 23:12:28 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Jul 2014 23:12:28 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.83 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.83 smtp83.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.83] ([108.166.43.83:58312] helo=smtp83.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DF/F3-37298-BD607C35 for ; Wed, 16 Jul 2014 19:12:28 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 975CF18108A; Wed, 16 Jul 2014 19:12:24 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 207EC181063; Wed, 16 Jul 2014 19:12:24 -0400 (EDT) X-Sender-Id: smalyshev@sugarcrm.com Received: from Stass-MacBook-Pro.local ([UNAVAILABLE]. [74.85.23.222]) (using TLSv1 with cipher DHE-RSA-AES128-SHA) by 0.0.0.0:465 (trex/5.2.4); Wed, 16 Jul 2014 23:12:24 GMT Message-ID: <53C706D7.3010200@sugarcrm.com> Date: Wed, 16 Jul 2014 16:12:23 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Andrea Faulds , Zeev Suraski CC: Rowan Collins , "internals@lists.php.net" References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <16D48604-0C0A-4613-91A4-21392E3A2636@ajf.me> <05CE2216-C5D9-4937-9F2E-AA1407284D9F@ajf.me> <53C460DF.5040304@sugarcrm.com> <53C53A96.2040303@gmail.com> <53C55342.1010207@sugarcrm.com> <53C563B3.6060905@gmail.com> <54536191-1B92-4933-973F-0C8289D13A4C@ajf.me> <00d12255efc53466245b21a83ff7d474@mail.gmail.com> <53C652FA.6010704@gmail.com> <53C66D6E.9060200@gmail.com> <60f496756412de6ad97751d91ead5058@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening) From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > The problem with making this RFC do the lossy thing is it then > removes one key advantage of it: that this RFC provides a measure of > strictness. Without that, we have no real compromise proposal, and we > might as well introduce a second set of “strict” type hints. The > whole point of the current behaviour is that it compromises between > the weak typing and strict typing camps; doing what zpp does is > giving in to the former camp, and then it’s not a compromise any > more, is it? I think if the compromise is having multiple set of rules for implicit casts then this compromise is not worth it. If you answer to the question of "what happens if I use a string in boolean context" with "well, it depends, if it's boolean context in syntax construct, it's one rule, if it's internal function, another, if it's user function, yet another" - it's not a good compromise. Any solution where you can give an actual answer like "empty string is false, all others are true" is much better. I'm not a fan of strict types in PHP, but having inconsistent rules is IMO so bad that even strict types would be better. At least you'd then know on which planet you are. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/