Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58344 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 68838 invoked from network); 29 Feb 2012 19:14:29 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Feb 2012 19:14:29 -0000 Authentication-Results: pb1.pair.com header.from=kris.craig@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=kris.craig@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender) X-PHP-List-Original-Sender: kris.craig@gmail.com X-Host-Fingerprint: 74.125.82.54 mail-ww0-f54.google.com Received: from [74.125.82.54] ([74.125.82.54:47705] helo=mail-ww0-f54.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 8A/E4-46815-3197E4F4 for ; Wed, 29 Feb 2012 14:14:28 -0500 Received: by wgbdq13 with SMTP id dq13so2401100wgb.11 for ; Wed, 29 Feb 2012 11:14:25 -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 v6mr20170767wif.10.1330542865336 (num_hops = 1); Wed, 29 Feb 2012 11:14:25 -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=fmzWBYyZm3FmfdYA6HwEIm02dvJ+Q8SAMLrS2wMgPl4=; b=Mx2jvg5TiGVtDnkiYgJmDlrH68T3+cRNCq/ckld2JlBUsxHaB/2WG6cwIq8ZKsp3uv /AJpcGMxwuxm5zwhBLOXjddImIkF9K9cLsm0Wcw4zIWgo3mktn/Op3cYo9SVVw/g1rv3 94SQffpr0WE5rEr5ZsGl0dE8c2B+oP4dwEV5Y= MIME-Version: 1.0 Received: by 10.180.24.166 with SMTP id v6mr16079712wif.10.1330542865286; Wed, 29 Feb 2012 11:14:25 -0800 (PST) Received: by 10.223.75.146 with HTTP; Wed, 29 Feb 2012 11:14:25 -0800 (PST) In-Reply-To: References: <693e15008681dfe7372eaea66214f8a8.squirrel@www.l-i-e.com> <4F4D5D44.5090307@developersdesk.com> Date: Wed, 29 Feb 2012 11:14:25 -0800 Message-ID: To: Richard Lynch Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary=f46d04182610d807b304ba1f2614 Subject: Re: [PHP-DEV] Scalar type hinting From: kris.craig@gmail.com (Kris Craig) --f46d04182610d807b304ba1f2614 Content-Type: text/plain; charset=ISO-8859-1 Now that I think of it, this would probably be a good argument for differentiating between strong and weak. Looking back to my previous comment, it probably would be best to have it behave the same regardless of what the incompatible type is. But in the case where a float might sneak its way into an int, the developer might decide that going with a weak type would make it more flexible (though if it was me, I'd just do a round or leave it a mixed type lol). --Kris On Wed, Feb 29, 2012 at 11:09 AM, Kris Craig wrote: > @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 >> >> > --f46d04182610d807b304ba1f2614--