Re: [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept

Hi, Lazare In your examples you are accessing an maybe non-existing array-key. This will raise an E_NOTICE. See the note below this example: http://php.net/manual/en/language.types.array.php#example-85 Maybe you also want something like that: isset($x) ? (is_null($x) ? null : (int)$x) : null But let's discuss that in a different thread. Bye Simon 2012/3/5 Lazare Inepologlou <linepogl@gmail.com> > 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 <ircmaxell@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 > > <weierophinney@php.net> wrote: > > > On 2012-03-02, Anthony Ferrara <ircmaxell@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 | matthew@zend.com > > > Zend Framework | http://framework.zend.com/ > > > PGP key: Xð” > > > âÝ»ª&!^ÂEbÊ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 > > > > >