Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58340 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 40241 invoked from network); 29 Feb 2012 18:02:39 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Feb 2012 18:02:39 -0000 Authentication-Results: pb1.pair.com smtp.mail=ceo@l-i-e.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ceo@l-i-e.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain l-i-e.com designates 67.139.134.202 as permitted sender) X-PHP-List-Original-Sender: ceo@l-i-e.com X-Host-Fingerprint: 67.139.134.202 o2.hostbaby.com FreeBSD 4.7-5.2 (or MacOS X 10.2-10.3) (2) Received: from [67.139.134.202] ([67.139.134.202:2559] helo=o2.hostbaby.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 28/77-33921-E386E4F4 for ; Wed, 29 Feb 2012 13:02:38 -0500 Received: (qmail 86417 invoked by uid 98); 29 Feb 2012 18:02:38 -0000 Received: from localhost by o2.hostbaby.com (envelope-from , uid 1013) with qmail-scanner-2.05 ( Clear:RC:1(127.0.0.1):. Processed in 0.036885 secs); 29 Feb 2012 18:02:38 -0000 Received: from localhost (HELO www.l-i-e.com) (127.0.0.1) by localhost with SMTP; 29 Feb 2012 18:02:37 -0000 Received: from webmail (SquirrelMail authenticated user ceo@l-i-e.com) by www.l-i-e.com with HTTP; Wed, 29 Feb 2012 12:02:38 -0600 Message-ID: In-Reply-To: References: <693e15008681dfe7372eaea66214f8a8.squirrel@www.l-i-e.com> <4F4D5D44.5090307@developersdesk.com> Date: Wed, 29 Feb 2012 12:02:38 -0600 To: internals@lists.php.net User-Agent: SquirrelMail/1.4.21 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: [PHP-DEV] Scalar type hinting From: ceo@l-i-e.com ("Richard Lynch") On Tue, February 28, 2012 5:17 pm, Kris Craig wrote: Some cases I would find interesting to be explained: (using 'streak' for strong and/or weak, feel free to separate the two) streak int $i = 123.456; //Common idiom for floor() streak int $i = "123.456"; //In contrast to previous streak int $i = "1 "; //value="1 " is ridiculously common HTML It's all well and good to say that any loss of data is "bad" and to raise some E_* for it, but there are some idioms so common that feel "wrong" as I consider them... If everyone "for" the new type hinting/forcing can reach consensus on these sorts of cases, it would help clarify any RFCs a bit, I think wrt E_RECOVERABLE_ERROR vs E_WARNING If current type hinting raises E_RECOVERABLE_ERROR, I have no objection to following that lead, with the explicit caveat that a change to the existing type-hinting to E_WARNING, as unlikely as that seems, would pull the new "streak" with it. I don't even object to using E_ERROR for the "strong" variant, if that passes review, really, since "strong" is, errr, strong. :-) Anybody who doesn't like the E_* can re-define them in a custom error handler anyway, though allowing PHP to continue after E_ERROR is like playing russian roulette... -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE