Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58180 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 39594 invoked from network); 27 Feb 2012 19:35:03 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Feb 2012 19:35:03 -0000 Authentication-Results: pb1.pair.com header.from=john.lesueur@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=john.lesueur@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: john.lesueur@gmail.com X-Host-Fingerprint: 74.125.82.54 mail-ww0-f54.google.com Received: from [74.125.82.54] ([74.125.82.54:58455] helo=mail-ww0-f54.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 12/32-29394-5EADB4F4 for ; Mon, 27 Feb 2012 14:35:02 -0500 Received: by wgbdq13 with SMTP id dq13so536178wgb.11 for ; Mon, 27 Feb 2012 11:34:58 -0800 (PST) Received-SPF: pass (google.com: domain of john.lesueur@gmail.com designates 10.180.93.4 as permitted sender) client-ip=10.180.93.4; Authentication-Results: mr.google.com; spf=pass (google.com: domain of john.lesueur@gmail.com designates 10.180.93.4 as permitted sender) smtp.mail=john.lesueur@gmail.com; dkim=pass header.i=john.lesueur@gmail.com Received: from mr.google.com ([10.180.93.4]) by 10.180.93.4 with SMTP id cq4mr30980808wib.21.1330371298462 (num_hops = 1); Mon, 27 Feb 2012 11:34:58 -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=xPjHzO1R4CRyz/oDHIGFt7+MZ4PMRXK1rvj6CKAQ/r8=; b=ARHDbY3SzvgF7sdIiwJCxtwmUEORKIrZAhy3xCs/6PAKsG5iqw09xDS7bFtoDAu+hl 74czrjHnblfin0LrcFMZMVPJYa+HNzzLsF1J7j+F9D5wk2NJ0IpprIPJzVFRhd+jZBlL 4GGX18vnVnmbB7oV4uqX4Vw2U+gczj0Q3WVWk= MIME-Version: 1.0 Received: by 10.180.93.4 with SMTP id cq4mr24563309wib.21.1330371298388; Mon, 27 Feb 2012 11:34:58 -0800 (PST) Received: by 10.216.50.213 with HTTP; Mon, 27 Feb 2012 11:34:58 -0800 (PST) In-Reply-To: References: <1330357150.2159.30.camel@guybrush> Date: Mon, 27 Feb 2012 12:34:58 -0700 Message-ID: To: Kris Craig Cc: Anthony Ferrara , Ferenc Kovacs , Michael Morris , "internals@lists.php.net" Content-Type: multipart/alternative; boundary=f46d043c8068a8e91204b9f7345e Subject: Re: [PHP-DEV] Scalar type hinting From: john.lesueur@gmail.com (John LeSueur) --f46d043c8068a8e91204b9f7345e Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 27, 2012 at 12: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). > - Strong, on the other hand, would throw a fatal error if you attempted > to pass an incompatible value to an array. Or, to put it another way, if > the "converted" value does not match the original value. For example, if > we're assigning "aaa" to an integer, that would convert to 1; and, since > "1" != "aaa", a fatal error would be thrown. On the other hand, if you > were to pass the string "1" to that integer variable, it would convert to > 1; and, since "1" == 1, there wouldn't be a problem. > - In both instances, if the converted value matches the original (i.e. > "1" == 1), no warning error would be displayed. Should it perhaps > display > a notice though? Or no error at all? I can think of reasonable > arguments > on both sides of that question. > > This new term would also make it easier for us to avoid using the term > "strict," which would explode even in the case of "1" == 1. > > Whether this should be done at the function level, the variable level, or > both is an open-ended question. > > > Some possible examples of how this would look: > > weak int $i = "aaa"; // Converts to 1 and throws a warning. > strong int $ii = "aaa"; // Throws a fatal error. > weak int $i = "1"; // Converts to 1. > strong int $ii = "1"; // Converts to 1. > > > --Kris > > Maybe this discussion should start from the end of the last discussion on non-strict type hints, where really smart people came up with some options to handle the conversion: https://wiki.php.net/rfc/typecheckingstrictandweak#option_1_current_type_juggeling_rules_with_e_strict_on_data_loss The RFC talks about throwing E_STRICT or E_FATAL, and has a couple of options for a matrix of conversion rules. I don't think we need another name for weak type hints, since the name covers anything less than strict, and anything more than none. There's been enough confusion about the names of things without adding another name for a variation of weak type hints. If I recall, the previous effort died due to the emotional stress of getting to the point where the differences between strict type hints and non-strict type hints was well understood, and everyone's position on those two points was crystallized. There were still a few proponents of strict type hints, but it seemed they were willing to live with non-strict type hints. At that point, everyone became more interested in having a 5.4, and scalar type hints were left for a time. Hopefully I haven't mischaracterized anyone's position, but I hope it helps us move beyond previously trod ground. John --f46d043c8068a8e91204b9f7345e--