Newsgroups: php.internals,php.internals Path: news.php.net Xref: news.php.net php.internals:20030 php.internals:20031 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 14296 invoked by uid 1010); 15 Nov 2005 21:08:38 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 14280 invoked from network); 15 Nov 2005 21:08:38 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Nov 2005 21:08:38 -0000 X-Host-Fingerprint: 87.123.69.142 i577B458E.versanet.de Received: from ([87.123.69.142:26053] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id A6/5D-07637-E984A734 for ; Tue, 15 Nov 2005 15:44:15 -0500 To: internals@lists.php.net,Rasmus Lerdorf Message-ID: <437A489B.2010008@php.net> Date: Tue, 15 Nov 2005 21:44:11 +0100 User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: Wez Furlong , Jani Taskinen , internals@lists.php.net References: <437A0D24.6030701@caedmon.net> <20051115181307.18c2b27b@localhost.localdomain> <437A1820.8060902@lerdorf.com> <437A1BD1.9030309@lerdorf.com> <4e89b4260511150942g6f3cab3boad1c09eb1c1e7318@mail.gmail.com> <437A1EEB.7@lerdorf.com> In-Reply-To: <437A1EEB.7@lerdorf.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 87.123.69.142 Subject: Re: [PHP-DEV] date() behaviour changed in 5.1? From: lsmith@php.net (Lukas Smith) Rasmus Lerdorf wrote: > Wez Furlong wrote: > >> I can't think of any case where you'd want to error out when given >> '100 ' if it would accept '100' quite happily. >> >> I'd lean towards a single cast semantic for this, and remove that >> strict checking flag from zend_parse_parameters(); lazy dynamic type >> handling for primitive data types is one of the cornerstones of PHP >> IMO. > > > Yeah, I am leaning towards that as well. I don't like the inconsistency > between direct casting via (int) vs. zend_parse_parameter's strict > casting. It is much simpler to explain that functions will cast to the > required parameter type and have one consistent way to cast things. +1 this is really what i have come to expect from PHP (which is why I never understood why we changed array_merge to not cast null to an empty array back in PHP 5.0.0) regards, Lukas