Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58343 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 67430 invoked from network); 29 Feb 2012 19:09:49 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Feb 2012 19:09:49 -0000 Authentication-Results: pb1.pair.com smtp.mail=kris.craig@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=kris.craig@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender) X-PHP-List-Original-Sender: kris.craig@gmail.com X-Host-Fingerprint: 74.125.82.170 mail-we0-f170.google.com Received: from [74.125.82.170] ([74.125.82.170:63814] helo=mail-we0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id BB/94-46815-CF77E4F4 for ; Wed, 29 Feb 2012 14:09:48 -0500 Received: by werh12 with SMTP id h12so2791228wer.29 for ; Wed, 29 Feb 2012 11:09:45 -0800 (PST) Received-SPF: pass (google.com: domain of kris.craig@gmail.com designates 10.180.24.166 as permitted sender) client-ip=10.180.24.166; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kris.craig@gmail.com designates 10.180.24.166 as permitted sender) smtp.mail=kris.craig@gmail.com; dkim=pass header.i=kris.craig@gmail.com Received: from mr.google.com ([10.180.24.166]) by 10.180.24.166 with SMTP id v6mr20139611wif.10.1330542585946 (num_hops = 1); Wed, 29 Feb 2012 11:09:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2KLBxp/NAacJli64sj/qwVFlfsOxm7KZqPhoeWU71lA=; b=IL5kaKz3i6lfiNPX9sS0GwASn1AO/d9bS82GWqLJWZdTPxdnlBysZP9+R+PApMLtbO HSltl6rt8a1zRms+We/t9H5CJFiT/sYjtgDOSwX2CUUHBjQqU5LVx5BHUI7XnT21InKk PcdttrdBvcfai08rBi1Y795WZdThv5OCbPykc= MIME-Version: 1.0 Received: by 10.180.24.166 with SMTP id v6mr16054614wif.10.1330542585815; Wed, 29 Feb 2012 11:09:45 -0800 (PST) Received: by 10.223.75.146 with HTTP; Wed, 29 Feb 2012 11:09:45 -0800 (PST) In-Reply-To: References: <693e15008681dfe7372eaea66214f8a8.squirrel@www.l-i-e.com> <4F4D5D44.5090307@developersdesk.com> Date: Wed, 29 Feb 2012 11:09:45 -0800 Message-ID: To: Richard Lynch Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary=f46d041826102fa24f04ba1f16f4 Subject: Re: [PHP-DEV] Scalar type hinting From: kris.craig@gmail.com (Kris Craig) --f46d041826102fa24f04ba1f16f4 Content-Type: text/plain; charset=ISO-8859-1 @Richard I think you made a very good point. Should we treat a float => int mismatch the same as we would a string => int mismatch, or should the former fail more gracefully? I can see good arguments for both. --Kris On Wed, Feb 29, 2012 at 10:02 AM, Richard Lynch wrote: > 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 > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --f46d041826102fa24f04ba1f16f4--