Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58746 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 18006 invoked from network); 7 Mar 2012 18:12:29 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Mar 2012 18:12:29 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 207.97.245.173 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 207.97.245.173 smtp173.iad.emailsrvr.com Linux 2.6 Received: from [207.97.245.173] ([207.97.245.173:35832] helo=smtp173.iad.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id EB/A5-15180-C05A75F4 for ; Wed, 07 Mar 2012 13:12:28 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp47.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id E6EFE3A9612; Wed, 7 Mar 2012 13:12:25 -0500 (EST) X-Virus-Scanned: OK Received: by smtp47.relay.iad1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 4BBC43A9606; Wed, 7 Mar 2012 13:12:25 -0500 (EST) Message-ID: <4F57A508.9000607@sugarcrm.com> Date: Wed, 07 Mar 2012 10:12:24 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Anthony Ferrara CC: "internals@lists.php.net" References: <52.38.15021.3A1E65F4@pb1.pair.com> <4F570EBB.6030103@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Scalar Type Hinting From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > would make even less sense, since it would need to be cast, so the > following would return false: > > function foo((string) $bar = 123) { > return $bar === 123; > } > foo(); You explicitly said "convert, then compare excluding conversion", what would you expect? That's like saying "why $a+1 is not equal to $a, it's almost the same?". No it's not - you just told PHP to modify it! > How much more confusing is that? By restricting the default parameter > to be of the type being casted to, that sort of a problem wouldn't > happen and would be adverted by the compiler... I feel you're painting yourself into a corner here - inventing arbitrary restrictions and then inventing arbitrary problems to justify these restrictions. Why would your conversion convert, but not always convert? Why it would work with constants, but not in defaults? > It is proper PHP code. It parses just fine > (http://codepad.viper-7.com/rEHqZp). Sure, it's not best practice The fact it parses doesn't mean it is proper code. The fact it's not errors out is actually a bug, as such function definition is broken. But let's not take the discussion too far out - just please do not promote such code in our RFCs. > The compiler (and any IDE) knows what the type of the variable will be > inside the function body. How is that not hinting? Hinting means something that is just for information and can be ignored it you don't need it. This is type coercion - you can not ignore it, it would change your variables. Calling it hinting implies it does not do anything, just informs IDE - that'd what PHPDoc does, but that's not what your proposed function does. Proper naming is important. The compiler BTW doesn't know anything and has no way to know it and benefit from it in any way. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227