Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:75407 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 50403 invoked from network); 13 Jul 2014 14:59:56 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Jul 2014 14:59:56 -0000 Authentication-Results: pb1.pair.com smtp.mail=jocelyn.fournier@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=jocelyn.fournier@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.171 as permitted sender) X-PHP-List-Original-Sender: jocelyn.fournier@gmail.com X-Host-Fingerprint: 74.125.82.171 mail-we0-f171.google.com Received: from [74.125.82.171] ([74.125.82.171:55867] helo=mail-we0-f171.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A1/76-16748-AEE92C35 for ; Sun, 13 Jul 2014 10:59:55 -0400 Received: by mail-we0-f171.google.com with SMTP id p10so421368wes.2 for ; Sun, 13 Jul 2014 07:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=XfCm9c3bLpQ26x4A7sZKnw/s37ygt1unjDO6WR4zuGM=; b=aew1fqFCyrR7UIDONB0vQAmPy1CdVAjCEdDnDR+pbQOQ/P5IPLLpwRP7gh+gAn8ITY iojOFALRdyALi1CVdBnKS648o6Zl9meqnBfysstF7H0m9sAU7j8dESSvC74ebLAfGPk6 v9AyakP/3TQ5Kd6Lsl8OPYDLCsMhYT7+I3pqFMBcSE39hDt/MBE1wfJ+2fP6SKmm6og/ RXYIZfoOxhVN2e7DmNrTuYS0Z4gRsENooI+mHAxpsBz0Tstot6mnknRrCGFMZze+xev9 DEyJrJaY8s5t0hh2/l0DNXiadaRW6AocRrCfnbi0/sdddUfpgMJHf/k3nIAbhueLxLvl Tmcg== X-Received: by 10.194.186.178 with SMTP id fl18mr12334836wjc.83.1405263591440; Sun, 13 Jul 2014 07:59:51 -0700 (PDT) Received: from MacBook-Pro-de-jocelyn-fournier.local (ven06-1-82-234-156-61.fbx.proxad.net. [82.234.156.61]) by mx.google.com with ESMTPSA id ey16sm19695313wid.14.2014.07.13.07.59.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Jul 2014 07:59:50 -0700 (PDT) Message-ID: <53C29EE4.3090808@gmail.com> Date: Sun, 13 Jul 2014 16:59:48 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Zeev Suraski , Andrea Faulds CC: PHP internals References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <027E65EF-C4FC-474C-92BB-D99EFADDEEED@ajf.me> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening) From: jocelyn.fournier@gmail.com (Jocelyn Fournier) Le 13/07/2014 16:41, Zeev Suraski a écrit : >> -----Original Message----- >> From: Andrea Faulds [mailto:ajf@ajf.me] >> Sent: Sunday, July 13, 2014 5:34 PM >> To: Zeev Suraski >> Cc: Nikita Popov; PHP internals >> Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening) >> >> >> On 13 Jul 2014, at 15:31, Zeev Suraski wrote: >> >>> I think this is a big step in the wrong direction to one of the most >>> common auto-conversion use cases out there (HTTP input variables). >>> See my note to Nikita... >>> >>> This RFC is a huge deal, I suggest we let more people voice their >>> opinion in before changing it in each direction :) >>> >>> Zeev >> >> Yes, I might have acted a little too quickly. However, I'm not sure > "12a" is such >> a common case. With the strict behaviour, foobar(" 12") and foobar("12") > still >> work, however foobar("12 ") unfortunately would not. > > I don't think it's a common intentional case, but when writing code > defensively - you need to be prepared for whatever someone might through > at you... Say I have a form that accepts 'age', and I expect users to > type in their age. As one that develops the backend, it's great if I can > simply stick an 'int' in the function signature that deals with this > $_GET['age'], and know that whatever the user typed in - it would turn it > to the most sane integer value. In other words, if someone types in '12a' > (by mistake or intentionally), I think it's a very sane behavior to just > treat it as 12, as opposed to forcing me (the developer) to write error > handling code with a try/catch block, and a fairly hairy try/catch block > too. Your example of "12 " (that I didn't even think about before) is an > even a more likely scenario, but I think there's no strong reason not to > allow both. From my point of view, if the type annotations are doing implicit cast (with or without E_NOTICE/E_STRICT warning), they should behave exactly the same than an explicit cast. If it behaves differently, I'll be really difficult for a developer to guess what will be the PHP behaviour with this new syntax. Jocelyn