Anthony, I still don't like the null-as-a-default-value solution. I find it confusing.
I know that something similar appears in class type hinting, but: 1. Class type hinting does not do casting (yet). 2. Apart from null, no other value could be placed anyway. (Even that is a little bit wrong as null belongs to a different type than the hinted class). ------- I have a different proposal. The argument type hinting/casting should not be bothered with that at all. Instead, we could expand the type juggling system a little bit, with the introduction of a special type of casting that leaves null unchanged. Something like this: (int?) $x which should be strictly translated to the following, without any way to change that behavior by any type casting overload system: is_null($x) ? null : (int)$x Examples: (int?) 13 // 13 (int?) '' // 0 (int?) 0 // 0 (int?) null // null (int?) '342.3Test' // 342 I can think of many real world scenarios that could benefit from this. The first that comes to my mind is reading from a database, in cases that the value of null totally different than the value of 0. $parent_id = (int?) $db['PARENT_ID']; // null and 0 mean different things here... A second example is reading from the query string: $id = (int?) @$_GET['id']; // the error-silencing operator will return null on error. Thoughts? Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/5 Anthony Ferrara <ircmax...@gmail.com> > Matthew, > > Have you seen the new thread and RFC around this? > https://wiki.php.net/rfc/parameter_type_casting_hints > > I went with option A, as I see erroring on cast as a more general > problem. So for consistency, I implemented it exactly like normal > explicit casts... > > Anthony > > On Mon, Mar 5, 2012 at 10:27 AM, Matthew Weier O'Phinney > <weierophin...@php.net> wrote: > > On 2012-03-02, Anthony Ferrara <ircmax...@gmail.com> 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. > > > > <snip> > > > >> 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 | matt...@zend.com > > Zend Framework | http://framework.zend.com/ > > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
