Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83868
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <09da01d05174$cd7382e0$685a88a0$@php.net>
References: <7ef509ef10bb345c792f9d259c7a3fbb@mail.gmail.com>
	<CAAyV7nHq_-9jyRcwJmiAxthmEo3u3MDXcyOC09LV2DETABzCoA@mail.gmail.com>
	<8250289916f5128b5bc1a114428d374e@mail.gmail.com>
	<CAAyV7nHAicJCQU87YkhZ700a=k4MRqVJtMV-mG4F0MQsn82OfQ@mail.gmail.com>
	<e7bfa71fe190a2577b329092b46da5dd@mail.gmail.com>
	<CAAyV7nGrh30VdYbU6j3oHwQHX_S81LdQ8iZAe4zZcAT1xOZ-uA@mail.gmail.com>
	<b72cac641e4bfddc212c01ae46a40ac5@mail.gmail.com>
	<CAEZPtU7dj3ezgbf1eNGxtbnOuc65R=Ljfe4-V6R1Wj4egcC8eQ@mail.gmail.com>
	<09da01d05174$cd7382e0$685a88a0$@php.net>
Date: Wed, 25 Feb 2015 21:02:47 -0800
Message-ID: <CAEZPtU6nvWbiWpZ672qwVgB1rO0CCwXbgCrBjaSrQ-cLsabjTA@mail.gmail.com>
To: francois@php.net
Cc: Zeev Suraski <zeev@zend.com>, Anthony Ferrara <ircmaxell@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
From: pierre.php@gmail.com (Pierre Joye)

On Wed, Feb 25, 2015 at 7:32 PM, Fran=C3=A7ois Laupretre <francois@php.net>=
 wrote:

> About #1: if, one day, a majority decides that we absolutely need strict =
types, it will be very easy. Just define four additional type hints, someth=
ing like 'int!', 'float!', 'string!' 'bool!' or any other syntax. These typ=
es would be defined as accepting only their native zval type and, of course=
, performing no conversion. And that's it. Nothing more. You have your stri=
ct types, function by function, argument by argument, return type too if yo=
u want. Isn't it nice ? We decided not to propose such types because we thi=
nk it would bring more bad than good. That's just an opinion. Do you see th=
e difference ? we don't propose strict types for 7.0 but, if you gather a m=
ajority favoring it, they may be present in 7.1.

I do not think this will even happen, not even in a distant future.

> About #2: The risk is not so terrible. As the default is to turn off E_DE=
PRECATED messages in production,  it is even very low. The highest risk we =
take is to see a small performance hit. Probably negligible compared to the=
 phpng positive impact on performance.

As I said earlier, E_DEPRECATED will only caught what it sees, we miss
what it does not and actually casts happily. There is no performance
hit, let get over that, we have published numbers to show that
already.

>  And temporary because developers will quietly fix their code and the hid=
den messages will disappear. So, we probably won't have to rely on 'good lu=
ck'.

Again. It seems you only see issues with this insignificant
E_DEPRECATED messages, it will be just like other or E_NOTICE, they
will disable it and move on. However my point is in a totally
different area, the one we have no idea what is going on because it is
now casted while it was not before. We do not have data to cover these
cases. It is not a lack of will but it is simply impossible to have
for all apps out there in production (as you said before). And it is
exactly why I am against changing the casting rules, even for a single
yota beyond what we have done already (or close to this area).


> FUD apart, every test Dmitry ran using his upcoming patch (which will imp=
lement E_DEPRECATED) on existing PHP software raised very few new errors. M=
ore : after analysis, all these messages except 1, I believe, correspond to=
 undetected bugs in the PHP code. Like the bug I detected in the PHP code t=
o build phar.phar. So, I can go further : we are not breaking anything *and=
* we are helping users to find undetected bugs in their codebase.  Nice sid=
e effect, isn't it ?

Again, see my previous comment in this mail.

Cheers,
--=20
Pierre

@pierrejoye | http://www.libgd.org