Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:20056 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 84980 invoked by uid 1010); 16 Nov 2005 08:41:30 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 84964 invoked from network); 16 Nov 2005 08:41:30 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Nov 2005 08:41:30 -0000 X-Host-Fingerprint: 204.11.219.139 lerdorf.com Linux 2.4/2.6 Received: from ([204.11.219.139:59769] helo=colo.lerdorf.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 2C/BD-07637-9B0FA734 for ; Wed, 16 Nov 2005 03:41:30 -0500 Received: from [192.168.200.106] (c-24-6-5-134.hsd1.ca.comcast.net [24.6.5.134]) (authenticated bits=0) by colo.lerdorf.com (8.13.5/8.13.5/Debian-3) with ESMTP id jAG8fK9r023142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 16 Nov 2005 00:41:24 -0800 Message-ID: <437AF0AF.50702@lerdorf.com> Date: Wed, 16 Nov 2005 00:41:19 -0800 User-Agent: Thunderbird 1.5 (Macintosh/20051025) MIME-Version: 1.0 To: Jani Taskinen CC: 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> <5D7AB792-4788-4C97-B523-7E15DAAB16E9@gravitonic.com> <437ADF38.9050900@lerdorf.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] date() behaviour changed in 5.1? From: rasmus@lerdorf.com (Rasmus Lerdorf) Jani Taskinen wrote: > On Tue, 15 Nov 2005, Rasmus Lerdorf wrote: > >> >> Derick Rethans wrote: >>> On Tue, 15 Nov 2005, Andrei Zmievski wrote: >>> >>>> Perhaps, but I would maintain that passing "123abc" and having it >>>> interpreted >>>> as 123 is still wrong. >>> >>> Yeah, I lean that way too, although trailing whitespace should be >>> supported IMO. >> >> I don't like having two different ways to cast things and I think we >> would break a lot of stuff if (int)"123abc" no longer resulted in 123. > > What has casting and passing a parameter have to do with each other > anyway? > IMO, they're totally different things. How is it not related? A function defined to take an int is passed "123" and it magically works. Or a function defined to take a string is passed 123 and that also magically works. How do you describe that other than through casting? Do you really want to document a different set of "function parameter type conversion rules" that have nothing to do with, and are completely different from casting? -Rasmus