Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83954
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender)
Reply-To: <francois@php.net>
To: "'Pierre Joye'" <pierre.php@gmail.com>,
	"'Zeev Suraski'" <zeev@zend.com>
Cc: "'PHP internals'" <internals@lists.php.net>
References: <d238d736f8fcde9e649cb38c9b05fcc1@mail.gmail.com> <CAEZPtU55N9XQWFVvRBdO0HQUhQvsffFbVnyd2GZ6sFp0L_J9_w@mail.gmail.com>
In-Reply-To: <CAEZPtU55N9XQWFVvRBdO0HQUhQvsffFbVnyd2GZ6sFp0L_J9_w@mail.gmail.com>
Date: Fri, 27 Feb 2015 03:39:04 +0100
Message-ID: <0acd01d05236$8dbb0520$a9310f60$@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQHbEgvqZ08kgCvmYfG4mXODzCFejgNqkVtynNLsJwA=
Content-Language: fr
Subject: RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC
From: francois@php.net (=?utf-8?Q?Fran=C3=A7ois_Laupretre?=)

> De : Pierre Joye [mailto:pierre.php@gmail.com]
>=20
> So far nobody answered this question but Francois (tried). You keep
> using this E_DEPRECATED message as a safety net to catch possible bad
> things.

Yes, even if we don't really 'catch' things, because we just raise =
E_DEPRECATED and, then, continue execution exactly as before. Actually, =
it is more an 'alert' net than a safety net, as its role is to alert =
developers that they have a potential issue to solve during the next 5 =
or 10 years. In most cases, it is a real bug they'd better fix before 5 =
years ;)

> What's about other changes that may not match the current
> casting rules (or lack of) and will be different with this RFC? Those
> considered as "Yes".

I now understand your previous post. There's absolutely no change in the =
way things are converted. Every conversion works *exactly* the same as =
in PHP 5. The only additional behavior we introduce is raising some =
E_DEPRECATED in some cases. But, after raising E_DEPRECATED, we still do =
the work ! So, if you turn E_DEPRECATED off, the behavior is exactly the =
same as PHP 5.

Even when E_DEPRECATED will be turned to fatal error in the future, the =
ruleset will remain a pure subset of the cases supported in PHP 5, =
failing for more cases, but with no change in the way conversion are =
performed. I think it is not clear enough in the RFC, explaining your =
misconception.

Actually, I must admit this is not *perfectly* true. There is one =
conversion I would like to modify. If we reintroduce getting bool from =
string, the current case for false is "0" or empty string only. For =
consistency reasons, I would like to extend "0" to any string that would =
convert to a null numeric value (also considering as false "0.0", "   =
0",...) but I hope you will consider that's a marginal change and the =
risk is low. But this is just a suggestion. Even for this, if some =
prefer to stick with the current behavior, it will be preserved and kept =
for a future RFC.

> Also I would really like a clear table describing in details what will
> be changed, to compare how it works now and how it work later.

You're right. I had planned to write two tables. One with the changes =
and one with the final situation. But I didn't have enough time for =
both. I will add the 'changes' table in the next hours.

Regards

Fran=C3=A7ois