Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58209 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 84319 invoked from network); 27 Feb 2012 22:34:07 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Feb 2012 22:34:07 -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.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:37842] helo=mail-we0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 89/A1-11273-FD40C4F4 for ; Mon, 27 Feb 2012 17:34:07 -0500 Received: by werh12 with SMTP id h12so1221792wer.29 for ; Mon, 27 Feb 2012 14:34:04 -0800 (PST) Received-SPF: pass (google.com: domain of kris.craig@gmail.com designates 10.180.99.100 as permitted sender) client-ip=10.180.99.100; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kris.craig@gmail.com designates 10.180.99.100 as permitted sender) smtp.mail=kris.craig@gmail.com; dkim=pass header.i=kris.craig@gmail.com Received: from mr.google.com ([10.180.99.100]) by 10.180.99.100 with SMTP id ep4mr32431847wib.7.1330382044989 (num_hops = 1); Mon, 27 Feb 2012 14:34:04 -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=QIjYI88wDYXAI3GStoEZmOlTnjnQBqK7AYIbCNje3I8=; b=Y03idT5BVV8ahkb91d/FsIXe8LR8SSGSr0WB+Eiv809KDC+hnR451RPUBbst9m54GY qnbXzsQf05DaWt21BUnSdFxJ6v+yJnyNYeZtypUGH9rFF6lF4nbEQmk1GnGlCenrJBlK PS/OjcvEQkiTh6GiYO21Tx3u8uuNH7+ZEAeho= MIME-Version: 1.0 Received: by 10.180.99.100 with SMTP id ep4mr25709752wib.7.1330382044924; Mon, 27 Feb 2012 14:34:04 -0800 (PST) Received: by 10.223.75.146 with HTTP; Mon, 27 Feb 2012 14:34:04 -0800 (PST) In-Reply-To: References: <1330357150.2159.30.camel@guybrush> Date: Mon, 27 Feb 2012 14:34:04 -0800 Message-ID: To: John Crenshaw Cc: Richard Lynch , "internals@lists.php.net" Content-Type: multipart/alternative; boundary=f46d04428e5c340b4a04b9f9b5c5 Subject: Re: [PHP-DEV] Scalar type hinting From: kris.craig@gmail.com (Kris Craig) --f46d04428e5c340b4a04b9f9b5c5 Content-Type: text/plain; charset=ISO-8859-1 I think this is the main reason for differentiating between "strong" (or whatever word is appropriate) and "weak." The developer may very well want their script to blow-up in such a case. I would liken this to the fact that we have both an "include" statement and a "require" statement. One is recoverable, the other is not. I think the same principle applies here. --Kris On Mon, Feb 27, 2012 at 2:31 PM, John Crenshaw wrote: > Inline > > > -----Original Message----- > > From: Richard Lynch [mailto:ceo@l-i-e.com] > > > > On Mon, February 27, 2012 1:15 pm, Kris Craig wrote: > > > Now, to rewind a bit past the latest chunk of "I hate this idea" > > > posts.... > > > > > > I'd like to suggest a new term: "strong". > > > > > > This term would be similar to "weak", except with a few key > > > differences: > > > > > > - Weak would behave very much like Arvids suggested in his earlier > > > post; > > > i.e. if the variable is an integer but you pass a string (like > > > "aaa") to > > > it, a warning would be thrown and PHP would attempt to convert it > > > (i.e. it > > > would become 1). > > > > Nitpick: > > Two backwards compatibility breaks: > > 1) Throwing E_WARNING > > 2) "aaa" converted to (int) is 0. > > Sorry, I don't understand the BC break on the warning. Old code doesn't > have this anyway, so what exactly would break? Shouldn't all existing > scripts continue to work exactly the same as before unless they add a type > check? > > (I'm sure the example was just wrong, "aaa" should convert to 0) > > > > strong int $ii = "aaa"; // Throws a fatal error. > > > > Okay. > > > > E_FATAL seems drastic to me, but I'm not even going to use "strong" so > don't really care either way, I suppose. > > I totally agree. E_RECOVERABLE_ERROR is the most severe that this should > be (also matches the behavior of current type hints). > > > > weak int $i = "1"; // Converts to 1. > > > > Again, old-school (int) or set_type covers this. > > Unfortunately it doesn't completely. Yes, behavior is the same so long as > the conversion is good, but a cast will silently accept impossible > conversions, which is not what you really want here. > > John Crenshaw > Priacta, Inc. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --f46d04428e5c340b4a04b9f9b5c5--