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

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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >