Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58310 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 15938 invoked from network); 28 Feb 2012 23:48:55 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Feb 2012 23:48:55 -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 209.85.220.170 as permitted sender) X-PHP-List-Original-Sender: kris.craig@gmail.com X-Host-Fingerprint: 209.85.220.170 mail-vx0-f170.google.com Received: from [209.85.220.170] ([209.85.220.170:32899] helo=mail-vx0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D0/41-36673-4E76D4F4 for ; Tue, 28 Feb 2012 18:48:53 -0500 Received: by vcbfo14 with SMTP id fo14so2283386vcb.29 for ; Tue, 28 Feb 2012 15:48:50 -0800 (PST) Received-SPF: pass (google.com: domain of kris.craig@gmail.com designates 10.52.71.114 as permitted sender) client-ip=10.52.71.114; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kris.craig@gmail.com designates 10.52.71.114 as permitted sender) smtp.mail=kris.craig@gmail.com; dkim=pass header.i=kris.craig@gmail.com Received: from mr.google.com ([10.52.71.114]) by 10.52.71.114 with SMTP id t18mr15371118vdu.88.1330472930450 (num_hops = 1); Tue, 28 Feb 2012 15:48:50 -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=AXzL8JhwQPN/as3Jw1oqiZo8jlSStAEz5fzZppwzZWc=; b=I1IXXjNCq7leHG7FEhrNGRezbwU/wAJLNgQZxQojotwoxIZZ1UC4ICIjARBTVNJuw0 uyqOwZDcTHCk5WZ5+rT8VNCUSsPipuivNkOQYHCjvh5cyc0orapdfdLj67Ti0zEQvTDI ai3Gg6kdPZWXunHFaC2Rhlfxl0ZuebZf9ybCE= MIME-Version: 1.0 Received: by 10.52.71.114 with SMTP id t18mr12708204vdu.88.1330472930103; Tue, 28 Feb 2012 15:48:50 -0800 (PST) Received: by 10.52.91.5 with HTTP; Tue, 28 Feb 2012 15:48:49 -0800 (PST) In-Reply-To: References: <1330357150.2159.30.camel@guybrush> <693e15008681dfe7372eaea66214f8a8.squirrel@www.l-i-e.com> <4F4D5D44.5090307@developersdesk.com> Date: Tue, 28 Feb 2012 15:48:49 -0800 Message-ID: To: Michael Morris Cc: PHP Internals List Content-Type: multipart/alternative; boundary=20cf3071d0d461d36e04ba0ede33 Subject: Re: [PHP-DEV] Scalar type hinting From: kris.craig@gmail.com (Kris Craig) --20cf3071d0d461d36e04ba0ede33 Content-Type: text/plain; charset=ISO-8859-1 Why is that 1 too many, exactly? Like I said, I would be ok with just having it behave as strong without the distinction, though that might be a harder sell for some people. On the other hand, having it just behave as weak without the option to blow it up would also be a harder sell for some people, myself included. That's why, from a pragmatic standpoint at least, having both levels makes the most sense without really having any glaring drawbacks, aside from the fact that some people might see it as superfluous. --Kris On Tue, Feb 28, 2012 at 3:41 PM, Michael Morris wrote: > It's better to have it blow up in all cases then. Avoiding the break is > trivial > > int $a = (int) 3; > > And this example illustrates cleanly the difference between this > proposal and casting by itself. Introducing this creates a new level > of typing, for a total of two. Your proposal creates 3, which is 1 > too many. > > On Tue, Feb 28, 2012 at 6:36 PM, Kris Craig wrote: > > But again, that same argument could be used to eliminate the require() > > function, which is something that I and many other developers use quite > > frequently. > > > > There are cases where I would want my script to blow-up and stop > executing, > > such as if an included script could not be loaded (hence "require"); or, > > given the right circumstances, when my script is relying on a variable > that, > > as a result of some unanticipated behavior, receives an incompatible > value > > for its type. > > > > After all, just look at how many PHP scripts out there already do this > > manually; i.e. terminating the script (with die() or some other means) if > > the variable doesn't pass a bulky and convoluted sanity check. All that > > code could be eliminated by simply having the strong type, since that > would > > now be done for you at the lower level. There are other cases where this > > sort of conflict would be undesirable but the coder might still want the > > script to proceed anyway, hence the need for the weak type. There are > > valid, real-world use cases for both. > > > > --Kris > > > > > > > > On Tue, Feb 28, 2012 at 3:30 PM, Michael Morris > > wrote: > >> > >> I don't see a point in two error levels. Either the coder cares or > >> they don't. Further, there are mechanisms already in place. > >> > >> int $a = 'House'; // Warning. > >> @ int $a = 'House'; // No warning because the suppression operator was > >> used. > >> > >> If you need something more than a warning you can code it. Let's use a > >> real world example > >> > >> @int $id = $_POST['id']; > >> > >> if ($id != $_POST['id']) { > >> throw MyValidationException(); > >> } > >> > >> In the language as it stands we have > >> > >> $id = (int) $_POST['id']; > >> > >> if ($id != $_POST['id']) { > >> throw MyValidationException(); > >> } > >> > >> So we have the means to make things secure. The one thing, the only > >> thing this is really going to give, is to prevent $a from changing > >> type. > >> > >> To be honest, this isn't useful with solo programmers. Where it will > >> be useful is with teams and API enforcement. > >> > >> This whole strong/weak keywording is a Very Bad Idea(TM) IMHO. Weak > >> can already be done with casting. > >> > >> On Tue, Feb 28, 2012 at 6:17 PM, Kris Craig > wrote: > >> > +1 on that. > >> > > >> > However, I believe the coder should also have the option of > determining > >> > whether this should be recoverable or not, just like they have a > choice > >> > with > >> > regard to using "include" or "require" (one fails gracefully, the > other > >> > terminates execution). > >> > > >> > That's where I think strong/weak could be very useful. Here's how I > >> > would > >> > do it: > >> > > >> > weak int $a = "House"; // Throws E_WARNING > >> > strong int $a = "House"; // Throws E_RECOVERABLE_ERROR > >> > > >> > > >> > In both cases, the error can be caught, which would mirror the > >> > flexibility > >> > in languages like C#. However, if the weak one isn't caught, the > >> > warning is > >> > thrown but the script proceeds as normal. If the strong one isn't > >> > caught, > >> > the script will terminate as if it was an E_ERROR. > >> > > >> > I think this would be the most sensible approach in terms of balancing > >> > simplicity and flexibility. > >> > > >> > --Kris > >> > > >> > > >> > > >> > On Tue, Feb 28, 2012 at 3:08 PM, Michael Morris < > dmgx.michael@gmail.com> > >> > wrote: > >> >> > >> >> Agreed. If conversion can occur without data loss (that is, if the > >> >> value being assigned is == the value that actually IS assigned) then > >> >> no error should occur. > >> >> > >> >> So > >> >> > >> >> int $a = "1"; // no error. 1 == "1" so who cares? > >> >> int $a = 'House'; // error 0 != 'House', so this is a problem. > >> >> > >> >> Again, errors should only raise if the final value != source value. > >> >> > >> >> On Tue, Feb 28, 2012 at 6:03 PM, Rick WIdmer > >> >> > >> >> wrote: > >> >> > On 2/28/2012 2:58 PM, Kris Craig wrote: > >> >> > > >> >> >> strong int $a = "1"; // Converts to 1. May or may not throw an > >> >> >> error > >> >> >> (I'm > >> >> >> still on the fence). > >> >> > > >> >> > > >> >> > It this is an error, it is no longer PHP. > >> >> > > >> >> > > >> >> > -- > >> >> > PHP Internals - PHP Runtime Development Mailing List > >> >> > To unsubscribe, visit: http://www.php.net/unsub.php > >> >> > > >> >> > >> >> -- > >> >> PHP Internals - PHP Runtime Development Mailing List > >> >> To unsubscribe, visit: http://www.php.net/unsub.php > >> >> > >> > > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --20cf3071d0d461d36e04ba0ede33--