> In addition, I'm voting no for the following reasons (in addition to > Dan's): > > 1. It downplays the BC breaks. It says: > > > Given the change to the acceptable values into a wide range of > internal > functions, this RFC is likely to result in a substantial number of newly > introduced E_DEPRECATED warnings in internal function invocations, > although those can be easily suppressed > > So BC breaks are fine, as long as they are *easily suppressed*. > This is madness, as they won't be able to be suppressed in 8 (when they > will > be turned into hard breaks).
If you copied the whole paragraph (one more sentence) instead of it out of context it would be clear that we're not at all downplaying anything. We're portraying it exactly for what it is, for better or worse. The fact users would have years to adjust is radically different from if we broke compatibility overnight, and that's exactly what this paragraph conveys. > 2. It judges the BC breaks based on skeleton applications (Drupal 7's > stock > home page, Drupal 7's stock admin interface, Magento's home page, > Wordpress's home page, ZF2's skeleton app, Symfony's ACME app). > It doesn't bring up unit tests (which Symfony was shown to have many > failures). It doesn't show running on non-framework code. It doesn't show > the average Wordpress/Drupal module for example. I don't consider Drupal/Magento or WordPress framework code. It's real world apps, very very similar to other custom-coded real world apps. > 3. It contains massive misinformation. > > > It is our position that there is no difference at all between > strict and > coercive typing in terms of potential future AOT/JIT development - none at > all. It's our position, the position of people very well versed in this area that have written a JIT compiler that runs blazingly fast with no type hints at all. It's fine that you have a different opinion. One of us is wrong. > Yet the JavaScript community is discovering the exact opposite, and is > looking into a extremely similar dual-mode: > https://developers.google.com/v8/experiments This is hardly the exact opposite. It means something we agreed on from the get go - if you *change* your code so that the compiler can gain more insight on what the types are during compile-time (e.g. an explicit cast, or if we add typed variable declarations) - then sure, there'll be AOT/JIT gains - but they're absolutely not coming from the difference in type hints. I still contend that with coercive type hints we can perform the exact same static analysis, with just differently phrased output such as "it may need to be converted" rather than "will be rejected". Identical type inference rules. Identical everything, just slightly modified text. > 4. It makes claims against the [dual mode > RFC](https://wiki.php.net/rfc/scalar_type_hints_v5) that apply to this > RFC. > For example: > > > Too strict may lead to too lax. In the Dual Mode RFC, when in Strict > mode, in many cases, functions would reject values that, semantically, are > acceptable. For example, a “32” (string) value coming back from an integer > column in a database table, would not be accepted as valid input for a > function expecting an integer. Since semantically the developer is > interested > in this argument-passing succeeding, they would have the choice of either > removing the integer STH altogether, or, more likely, explicitly casting > the > value into an integer. This would have the opposite of the desired outcome > of strict STHs - as explicit casts ($foo = (int) $foo;) always succeed, > and > would happily convert “100 dogs”, “Apples” and even arrays and booleans > into an integer. Further, since already today, internal functions employ > coercion rules that are more restrictive than PHP's explicit casting, > pushing > people towards explicit casting will actually make things worse in case > developers opt for explicit casting as they pass values in an internal > function > call. > > Yet it completely ignores the fact that the identical situation > appears with > the coercive mode RFC. The difference is that with Dual-Mode, it's 100% > opt- > in, where with coercive you're forced to add casts. That's one difference, but the real difference is that the rules are radically - and the coercive ones are what you'd almost always want to use in real life, while strict almost never is - which means a lot more explicit casts. The most popular conversion in PHP - string -> number - just works. With strict mode, it simply doesn't. Personally, I think that the 'it won't break until you actually flip it on' stance is weak. When people do flip it on (and they'd certainly be encouraged to do so by many people, e.g. your blog post from a few weeks ago) - they're going to see massive breakage which will in turn require massive explicit casting - resulting in much worse code than in the coercive type hints case. > 5. It's full of logical inconsistencies: > > For example, given the following code: > > function foo(bool $abc) {} > > These calls work: > > foo(true); > foo(1); > foo("test"); > > While these fail (note they don't fail on 5.x): > > foo(1.0); > foo(array()); > foo(null); > > Why is `int` accepted for `bool`, but `float` rejected??? Because int is commonly used in boolean context, which cannot be said about float (if you discount the PHP test suite, that is). This patch tries to provide real-world value and support real-world use cases - and blocks ones which are more than likely to be mistakes. The rules are designed to work in the vast majority of cases and support all the sensible conversions. You can always use explicit casting or otherwise refactor your code if you do bump into some edge case - but fact is, you'd bump into a lot less problems than if you flip on strict. > And that's not even mentioning that this has been put to vote without > having > the final version put up for discussion. There were [12 non-voting related > changes in the past 28 > hours](https://wiki.php.net/rfc/coercive_sth?do=revisions). Some of them > are likely trivial tweaks, but some like `allow int/string -> bool > conversion` > are definitely not trivial. I can't actually pull a diff of the changes > due to > errors on wiki.php.net, so I can't tell exactly what was changed... In terms of behavior that's the only thing that changed, and those were discussed publicly over a week ago. Guys, this isn't House Of Cards. Let's stay focused on substance. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
