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

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