Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44780
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 88.198.8.16 cause and error)
Cc: Ilia Alshanetsky <ilia@prohost.org>,
 PHP internals <internals@lists.php.net>
Message-ID: <6D12BDB9-35F6-4CB8-9E25-6571F4C51B59@pooteeweet.org>
To: Andrei Zmievski <andrei@gravitonic.com>
In-Reply-To: <4A53832E.6030105@gravitonic.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Tue, 7 Jul 2009 19:41:27 +0200
References: <2D0F5226-EBCA-4B45-BF01-8ED1C643976C@prohost.org> <4A53825F.1080006@gravitonic.com> <4A53832E.6030105@gravitonic.com>
Subject: Re: [PHP-DEV] Type hinting/casting request for vote
From: mls@pooteeweet.org (Lukas Kahwe Smith)

Hi,

I am -1 on the inclusion of cast support. IMHO this part isnt thought  
out and was just thrown in to silence those who feel that there is a  
use case for non strict type hinting. But in that case I might as well  
leave the type cast in the API calling code. The number of characters  
saved are next to nothing, the performance impact is probably also  
fairly irrelevant and with this syntax I get slapped and then I can  
choose if I want to cast manually or do something else. But just  
hiding things by just blindly casting seems counter productive (which  
is why I proposed to add reasonable checks before doing the cast in my  
RFC that would make things more compatible with data coming out of a  
database, config file or other trusted data source). I just do not see  
what is gained at all from:

A) foo((int)$bar);
function bar(int $bar) {}

vs.

B) foo($bar);
function bar((int) $bar) {}

What am I really saying with B)?
I don't care what you give me, I am going to use it as an int anyways?

IMHO no need to introduce a special syntax for this.

Of course I am also quite opposed to sticking this into 5.3.

Finally I would like to ask to rename this entire feature (including  
what we currently already have) to "type checking" or something other  
than "hint" in the documentation.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org