Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58600 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 46485 invoked from network); 5 Mar 2012 15:27:30 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Mar 2012 15:27:30 -0000 X-Host-Fingerprint: 208.107.21.52 host-52-21-107-208.midco.net Date: Mon, 05 Mar 2012 10:27:29 -0500 Received: from [208.107.21.52] ([208.107.21.52:28591] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E5/D1-35539-16BD45F4 for ; Mon, 05 Mar 2012 10:27:29 -0500 Message-ID: To: internals@lists.php.net References: User-Agent: slrn/pre1.0.0-18 (Linux) X-Posted-By: 208.107.21.52 Subject: Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept From: weierophinney@php.net (Matthew Weier O'Phinney) On 2012-03-02, Anthony Ferrara wrote: > Well, there are a few questions about the implementation: > > 1. *Which* type casting rules should it follow? > > a. Regular cast rules (like $foo = (int) $foo), where it converts > always without error? > b. Internal function cast rules, where it warnings on error and > prevents execution of the function. > c. Current type hinting rules, where if it can't convert cleanly it > E_RECOVERABLE_ERRORS > > Personally, I like C the best. Where if it is passed an invalid > value, it attempts to cleanly convert, but errors out if it can't... > But I can see other arguments being made... (c) seems the most sane option ot me as well. > 2. Should (array) be supported? Perhaps. So at that point, foo(array > $bar) would do a "strict" check, and foo((array) $bar) would attempt > to cast. But my question would be: what would attempt to cast mean? > Should it error out if you pass foo(1)? That's what the internal > function cast rules do. And to me that's more obvious than silently > converting it to foo(array(1))... Turn this around and look at it from the current state of PHP: function foo($bar) { $bar = (array) $bar; } If you pass a value of 1 for $bar, $bar is then converted to array(1). That's what I'd expect the following to do as well: function foo((array) $bar) { } It's casting, and clearly different than: function foo(array $bar) { } which is doing a typehint check. > 3. Should references be supported? My feeling is yes, they should. > So if you do foo((array) &$bar), it would cast the original value (if > possible) as well. I personally would expect casting and references to be mutually exclusive -- if you're casting, you're changing the value type, and I wouldn't expect a destructive operation like this from passing a value to a function/method call. > 5. What about BC breaks? Well, this entire patch (up to this point) > wouldn't require one. it's only adding the casting functionality > (which is not implemented today), so no problem. Existing code would > still function fine. This is something that should be highlighted. I've seen a lot of folks claiming type hinting is viral, and the arguments make no sense to me. What your patch is offering is _opt_in_ type casting of function/method arguments. You don't _have_ to write your functions or methods using them, and for those who do, it should have no side effects on code calling it. I would _LOVE_ to see this as part of PHP. -- Matthew Weier O'Phinney Project Lead | matthew@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc