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

> > In your examples you are accessing an maybe non-existing array-key Yes, this is why I used the error silencing (@) operator. But anyway, it is irrelevant to the whole proposal. Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/5 Simon Schick <simonsimcity@googlemail.com> > 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: http://framework.zend.com/zf-matthew-pgp-key.ascèÌm >> > > …0òÈÌ_þ°† >> > > >> > > -- >> > > 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 >> > >> > >> > >