Hi,
Am 03.01.2019 um 10:21 schrieb Zeev Suraski:
On Wed, Jan 2, 2019 at 8:57 PM Nikita Popov <nikita....@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
