Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:75614 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 62991 invoked from network); 16 Jul 2014 23:23:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Jul 2014 23:23:51 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.107 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.107 smtp107.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.107] ([108.166.43.107:46222] helo=smtp107.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 19/A4-37298-68907C35 for ; Wed, 16 Jul 2014 19:23:51 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp14.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 89A1518054B; Wed, 16 Jul 2014 19:23:48 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp14.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 006AA18016B; Wed, 16 Jul 2014 19:23:47 -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:23:48 GMT Message-ID: <53C70983.7040400@sugarcrm.com> Date: Wed, 16 Jul 2014 16:23:47 -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: Andrey Andreev , 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> <1CE2ACC0-D6CA-407B-99C7-4914311B733E@ajf.me> <53C6CFB7.8090908@sugarcrm.com> <118BB3D7-BE52-44AB-BD0E-942830D44A2A@ajf.me> <9B7B8559-61FE-493D-BAEE-53E8C84D5E91@ajf.me> <221d3e5c1be1ee2277e05027912762db@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! > E_CAST is problematic. Having something we encourage some people to > make an error and some people not to means that in some cases your > library works fine and rosy in other people’s environments and > sometimes it crashes your app. This is *not good*. We must not > encourage people to make things errors conditionally. It’s either an > error or not. I’d veer towards error. I think this is not correct. It can be OK in one context and error in another. I.e., if you say "let's ask users how many gizmos they want" and the user gives "1 " (note the space) and we tell them "we don't know what this even means, there's an extra character there" - doing this would just annoy the user. Silently converting it to 1 would do the right thing. If you say making any distinction between "1" and "1 " is useless for you - well, I can accept that. I can see use cases where it makes sense to make distinction but they are a minority. I think there's a level between E_RECOVERABLE_ERROR and silence where it's not "I can't make any sense out of this garbage" but also not "it's clean data". But I can also live without this level, if that is what the majority comes to. In that case, I'd rather have "1 " converted to 1 silently. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/