On Mon, Feb 23, 2015 at 6:08 PM, Zeev Suraski <z...@zend.com> wrote: > > -----Original Message----- > > From: Benjamin Eberlei [mailto:kont...@beberlei.de] > > Sent: Monday, February 23, 2015 6:54 PM > > To: Zeev Suraski > > Cc: PHP internals > > Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC > > > > Zeev, > > > > On Sat, Feb 21, 2015 at 11:25 PM, Zeev Suraski <z...@zend.com> wrote: > > > > > > Additional options we could entertain are: > > > > 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. > > > > > > 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. > > I don't see how that would affect PHP 7 adoption at all actually. You can > just disable E_DEPRECATED and your upgrade would be clean. Technically it > would have to wait to PHP 8 before we change it to E_RECOVERABLE_ERROR, > give > users several years to migrate.
Just disabling E_DEPRECATED is hiding bugs now. The error gets triggered *because* somebody uses the wrong coercion rules, if i hide this, how am i going to fix it? Compare this to Smarty/FPDF/TCPDF. Extremly wide adoption libraries, still php v4 code. They throw strict errors and notices like nothing you have ever seen before, but nobody talks about turning them into errors in PHP7/8. Furthermore, you said before this will be only 1-2 years, now until 8 we have another 8-10 years. > Given we're talking about coercive rules > and not strict rules, I actually don't expect that many failures (initial > tests of Francois' patch results in 8% failures in our unit tests, and > that's before tweaking the rules in any way (and apparently, at least some > of them have to do with bugs in internal functions that can be easily > fixed). It doesn't strike me as a worse migration than we did getting rid > of magic_quotes or safe_mode. It can be done. > 8% is alot. Now you are lucky that you have unit tests. The kind of code that will rely on this conversion probably does not have a single test. magic quotes has a workaround you can put into an auto_prepend_file, *magically* making it work this way before again. This changes here have no workaround to keep the old mode. > I'm personally now leaning towards this option as the most viable one. I agree if we can avoid an INI setting, but this will surely lead to a Python 2/3 situation. > > > 6. Ok, so this is now getting very similar like v5 of the STH, but still > > with much > > more BC breaks. > > Not at all. With the Dual Mode RFC, we're going to have declare() and two > distinct modes even in 10 and 20 years from now, for all eternity. It's a > new feature that's here to say. With this, these declare()'s are a > migration feature, that will be gone in several years. The endgame is > completely different. > Yes, I know, but it will not ever break BC with PHPv4/v5 compatible code. No upgrade problem for nobody. The problem with the coercive STH RFC is imho that ontop of introducing Typehints what we all want, it changes the ZPP rules. I would rather have a vote on v1 of the STH vs v5. And then changes to ZPP handling can be a completly different task, maybe for PHP8. > > Zeev >
