Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:57019 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 44858 invoked from network); 22 Dec 2011 19:20:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Dec 2011 19:20:08 -0000 Authentication-Results: pb1.pair.com smtp.mail=dsnytkine@Ultralogistics.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=dsnytkine@Ultralogistics.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain Ultralogistics.com from 64.197.110.172 cause and error) X-PHP-List-Original-Sender: dsnytkine@Ultralogistics.com X-Host-Fingerprint: 64.197.110.172 thrud.alliantinternet.com Received: from [64.197.110.172] ([64.197.110.172:59339] helo=thrud.alliantinternet.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6E/4D-12618-8E283FE4 for ; Thu, 22 Dec 2011 14:20:08 -0500 Received: by thrud.alliantinternet.com (Postfix, from userid 1001) id 24F66174331; Thu, 22 Dec 2011 14:20:05 -0500 (EST) To: "'Rasmus Lerdorf'" , "'Sebastian Bergmann'" Cc: References: <2095305E-D4E3-4D7E-8218-32EE99688E0C@GMAIL.COM> <2C90FB94-38C4-4270-8C6A-B89304BA8ED8@gmail.com> <159A7CA2-8561-40DA-9434-CAAE12304DDB@gmail.com> <005701ccc0b3$58c8dee0$0a5a9ca0$@alliantinternet.com> <20111222145159.GY25857@alliantinternet.com> <006101ccc0ba$46b81160$d4283420$@alliantinternet.com> <4EF379D8.9000206@lerdorf.com> <4EF37C29.1010206@php.net> <4EF3811A.7080100@alliantinternet.com> In-Reply-To: <4EF3811A.7080100@alliantinternet.com> Date: Thu, 22 Dec 2011 14:20:04 -0500 Message-ID: <007f01ccc0de$b578d750$206a85f0$@alliantinternet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AczA3cfXGb+fRepnSJuuob9omRkcVAAAMcxw Content-Language: en-us Subject: RE: [PHP-DEV] Return Type Hinting for Methods RFC From: dsnytkine@Ultralogistics.com ("Dmitri Snytkine") Not sure what you mean by json wrapped. In mongo you do $coll->find(array('age' => $age); if $age is a string '21' your will not get any erros but neither will you get any results. Dmitri Snytkine Web Developer Ultra Logistics, Inc. Phone: (888) 220-4640 x 2097 Fax: (888) 795-6642 E-Mail: dsnytkine@ultralogistics.com Web: www.ultralogistics.com "A Top 100 Logistics I.T. Provider in 2011" -----Original Message----- From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com] Sent: Thursday, December 22, 2011 2:12 PM To: Sebastian Bergmann Cc: internals@lists.php.net; Dmitri Snytkine Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC On 12/22/2011 10:51 AM, Sebastian Bergmann wrote: > Am 22.12.2011 19:41, schrieb Rasmus Lerdorf: >> This is not a step forward. If the author of age_check() really doesn't >> want to accept type-juggled arguments, then it is easy enough to do a >> strict type check in the function itself. This puts the effort in the >> correct place and doesn't encourage this type of coding. > > Putting such code into the "correct" place does not change the problem > that you and Stas describe > > function age_check($age) > { > if (!is_int($age)) { > throw new InvalidArgumentException; > } > } > > With the above code, the caller needs to cast and the writer of the > age_check() function has to copy/paste/adapt these checks to all the > correct places ... > > I am not advocating type hints for scalars, I am just saying that this > argument is not really a good one against it. But people don't really write code like this in PHP. Which is also why it makes very little sense to add strong typing of scalars. Why would anyone want to add a feature that lets them do something they would never do? The above code is much more likely to do an is_numeric() check and/or a hard typecast to an int. But throwing an exception when it receives "21" instead of 21 just isn't something people tend to do. And Dmitri, in the Mongo case you mentioned, parameters to Mongo need to be json-wrapped, so you are going to have access functions doing this. Why would you not want to typecast in the access function there as well as opposed to throwing hard to catch exceptions going into the access functions themselves? The only way I see something like this ever happening in PHP is if we came up with an intelligent approach that actually was type *hinting* and not strong typing. As in: function ((int)$age) { return ($age > 21) ?: false; } that would gracefully handle interchangeable types. But it gets tricky once we start thinking about non-numeric strings being passed in there. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php