Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83591
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain beberlei.de from 209.85.212.169 cause and error)
MIME-Version: 1.0
In-Reply-To: <f881d1e1bb6026b96498cfd787d3fd0a@mail.gmail.com>
References: <7ef509ef10bb345c792f9d259c7a3fbb@mail.gmail.com>
	<CAEPJduk3VgWYgpuJ4G0JvUXYaMoO7430Q0k7v5ifwWF_dzh9rA@mail.gmail.com>
	<9aec85c81b49009c6238ff6d8be27cd4@mail.gmail.com>
	<CAEPJdukoBG3M1q3UqJ9LW-GBqhVB7-ybkdJqiGENN2w10XqEhw@mail.gmail.com>
	<f881d1e1bb6026b96498cfd787d3fd0a@mail.gmail.com>
Date: Mon, 23 Feb 2015 18:20:17 +0100
Message-ID: <CAEPJdumFJup3mKsaYxi11O0f6L3BAvOUa=Z9tTKy8B01tvu8PQ@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bacb11eb78dc2050fc49dbd
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
From: kontakt@beberlei.de (Benjamin Eberlei)

--047d7bacb11eb78dc2050fc49dbd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 23, 2015 at 6:08 PM, Zeev Suraski <zeev@zend.com> wrote:

> > -----Original Message-----
> > From: Benjamin Eberlei [mailto:kontakt@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 <zeev@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=E2=80=99s 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 ca=
n
> just disable E_DEPRECATED and your upgrade would be clean.  Technically i=
t
> 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 som=
e
> 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 ri=
d
> 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 stil=
l
> > with much
> > more BC breaks.
>
> Not at all.  With the Dual Mode RFC, we're going to have declare() and tw=
o
> 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
>

--047d7bacb11eb78dc2050fc49dbd--