Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103679
To: internals@lists.php.net
References: <a7761c2f-5716-279b-d701-5f588b856277@gmx.de>
 <dbfae3d5-e317-f680-9fe6-240ab142d105@gmail.com>
 <94f5feb8-6589-3a0a-2849-7679cec1858c@gmx.de>
 <a0e50789-10c0-263d-f6a7-56486d7bb318@gmail.com>
 <CAF+90c-2ama6LBDY0xQKN1oPV-YMaY2==SSWk_hSstc40y9NWQ@mail.gmail.com>
 <CAJHtznzzBvx9Dc5YPGT6kU97doCj0O2FxGGjnTNh4Pv2-Pucxg@mail.gmail.com>
 <CAF+90c_i7802QYeBUkgyc81Yv2ASzSHYqxNrObcA+TxA_b_46A@mail.gmail.com>
 <CAJHtznwkU5nt3hPrE7f8X+cND3F6OMxTaFGBUZ6=Of_+rB0tsQ@mail.gmail.com>
 <CAF+90c-UdKJnM17uNXK51sHOYUdM+9BCtpofsBMz_8rBcUPM=Q@mail.gmail.com>
 <CAJHtznxdYEvWxFp4m5ypKFkrzeZFG3YJ_zTpbS0HFeviQy-inw@mail.gmail.com>
Message-ID: <4aaa9aa6-09fa-bfc8-f98b-9c3dfe17061d@phpgangsta.de>
Date: Thu, 3 Jan 2019 21:33:35 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <CAJHtznxdYEvWxFp4m5ypKFkrzeZFG3YJ_zTpbS0HFeviQy-inw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Inconsistent float to string vs. string to floatcasting
From: info@phpgangsta.de (Michael Kliewe)

Hi,

Am 03.01.2019 um 10:21 schrieb Zeev Suraski:
> On Wed, Jan 2, 2019 at 8:57 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
>> It's usually the other way around. The current behavior is prone to
>> breaking integration code, because data interchange layers generally do not
>> expect floats to use comma separators. The reason why things don't break
>> quite as terribly as they could is that PHP has introduced a number of
>> workaround over time, as these issues have been reported. That's why you
>> usually don't run into this when inserting float values into a DB query, at
>> least when using prepared statements. This issue is not handled everywhere
>> though (one recent example I remember is passing floats to bcmath) and I
>> don't think that introducing more of these special cases is how we should
>> be approaching this problem.
> Again, I'm not disputing that the current behavior isn't desired.  I am
> disputing that it's a "no big deal" to change it 20+ years after the fact,
> and I am disputing that while many may not be fond of this behavior - they
> can still have code that has grown to rely on it over the years.
>
> I do think that if we do decide to change it, it should be while providing
> users a long-term (and probably permanent) language level way to keep the
> current behavior.  Yes, it's against our motto - but then, so is such a
> widescale compatibility breakage without an easy forward path that does not
> involve a full line by line code audit.

Would it be possible to write a patch where every 
float-to-string-conversion that changes the representation because of 
the locale-setting, would produce a DEPRECATION or NOTICE or similar? 
The conversion output stays as it is today. Then people could run that 
patch against their own private projects. Or run against most popular 
100 PHP Github projects. Run against 1000 random PHP projects from 
Github. Or create a specific PHP version that could run on Travis-CI or 
so...

Currently there is a lot of guessing about the potentially affected 
libraries and projects, maybe it's better to measure. Then we get 
numbers of how many affected projects there might be. Maybe it's a huge 
problem, maybe only 0.001% of the projects are affected, and if they are 
affected, most likely it's considered a bug, not "intended behaviour". 
Nobody should rely on the current behaviour, best practice is to use 
number_format() if needed I think.

If such a DEPRECATION/NOTICE would be emitted in 7.4, 8.0, and 8.x, then 
people have many years to fix it before the change finally is done in 
9.0 or 10.0. We don't have to hurry, this might be a feature with a long 
period of DEPRECATION/NOTICE, potential bugs can be fixed during the 
years, before the final change happens. If there are really huge 
problems that we see during those years (but didn't see while 
measuring), thousands of developers complaining, in the worst case the 
change could be reverted.

We should measure first, and then hopefully fix strange behaviour of PHP 
in the long run.

Michael