Zeev, On Sat, Feb 21, 2015 at 11:25 PM, Zeev Suraski <z...@zend.com> wrote:
> Benjamin, > > > > There’s a fundamental difference between the two RFCs that goes beyond > whether using a global INI setting and the other per-file setting. The > fundamental difference is that the endgame of the Dual Mode RFC is having > two modes – and whatever syntax we’ll add, will be with us forever; and in > the Coercive STH RFC – the endgame is a single mode with no INI entries, > and opening the door to changing the rest of PHP to be consistent with the > same rule-set as well (implicit casts). The challenge with the Coercive > STH RFC is figuring out the best transition strategy, but the endgame is > superior IMHO. > Yes i confirmed this difference. So lets say i am totally against INI and hopefully many others are as well, then we introduce massive BC breaks in PHP 7. We got ourselves a Python2/3, Ruby1.8/2 situation here that nobody wants. I don't like the casting rules that PHP has now, but subtly breaking them *everywhere* (instead of with declare, by choice) is something I can't support. I can forsee Wordpress will not work with kind of BC anymore, so your (Zends) foremorst goal for PHP7 to get everyone to upgrade because the code is as fast as HHVM suddenly vanishes in thin air. > > Regarding the proposed migration options, yes, if we pick option #2 or #3 > – we’d be introducing an INI entry governing runtime behavior is something > nobody here wants, myself included – but given that it’ll be time limited > (perhaps for as short as 1 or 2 years) – perhaps that’s something we can > live with. > 1-2 years in php-src has absolutely no relation to how long this will be in userland, probably 2-5 times as long (2-10 years). You are against dual mode because people need to learn two different styles, however with some change like this lurking in old hosters and whatnot, how don't we have to learn about this as well? Its exactly the same thing. > > > Additional options we could entertain are: > > 4. Not applying the rules for internal functions at all. Personally I’m > not very fond of this option. > > 5. Go for just E_DEPRECATED in 7.0. Change E_DEPRECATED to > E_RECOVERABLE_ERROR in 7.1/7.2/8.0 (TBD). > > 6. Same as #5, but also provide a mechanism similar to declare() as the > temporary measure for strict campers to explicitly ask for > E_RECOVERABLE_ERROR’s to be triggered. They will no longer be necessary > when we change E_DEPRECATED to E_RECOVERABLE_ERROR in 7.1/7.2/8.0. > 4. Agree with you here, not an option. 5. BC Break too big leading to a Python2/3 situation, low adoption of PHP7, something that especially you couldn't want given that the perf improvements are what keeps PHP on level with HHVM. This automatically applies to all internal functions regardless if userland uses typehints or not, wordpress will not work with this anymore, no performance comparisons anymore. 6. Ok, so this is now getting very similar like v5 of the STH, but still with much more BC breaks. > > > Thoughts? > > > > Zeev > > > > I was really looking forward to the RFC. However the dependence on an INI > setting and the question of massive internal BC break are a bit too much I > think. > > > > They are necessary as you explain to allow internal functions/ZPP to have > the same conversion rules as userland functions. This INI setting is quite > similar to introducing two modes as well, but on the server configuration > level instead in a much more fine granular way in scalar type hints v0.5. > > > > I see much more compatibility problems for third party libraries here. > > > > Now if I had to decide between having two modes on a granular file level > or an INI setting (option 2/3) or massive BC breaks (option 1) to get > scalar type hints in PHP, then two modes with declare() doens't look, > because I can pick the mode I want, and no-one can force it on me. > > > > > > Zeev > > >
