On 29.12.2018 at 01:02, Stanislav Malyshev wrote: > >> As for me, the question is not *if*, but rather *when* and *how* this >> inconsistency should be resolved. Regarding the *when*, it seems to me > > If you mean that loading "0.3" from string would suddenly stop working > in Germany, then never. If you mean that (string)0.3 would return "0.3" > and not "0,3" in Germany, then again I'd say probably never, though very > slightly less confidently. Those people who didn't want it already have > code to deal with it, and those that wanted it would have their unit > tests crash and burn and their data pipelines blow up.
It seems to me that Nikita put it nicely[1]: > […] but core language behavior should *never* be locale-sensitive. So yes, (string)0.3 should return 0.3 in any locale. > I think it's a very bad idea to change such things, which would create > hundreds of year-persons of headache to anybody daring to upgrade. I > understand it's a bad situation, but I think the right exit of it is to > tell people that want predictable roundtrip results to use specific > number conversion functions, and not exchange one mess to another, > BC-breaking and havoc-wreaking, mess. I agree that the right thing to do > would be to have (string)0.3 to always use dot and never use locale (did > I mention I think global locale is a horrible idea?) but that ship has > sailed. I don't see a use case that would be well served by breaking the > BC now. Well, to begin with it would fix the broken behavior of var_export(), which is documented to “output or return a parsable string representation of a variable”, which it does not necessarily. Then, I'm not only thinking about the huge amount of existing code, but also about the huge amount of code yet to written. I'm pretty sure that many new PHP developers (especially those comming from other programming languages) stumble over the locale-aware float to string conversion sometime. Finally, I don't think that the global locale is the real problem for PHP. Rather it's PHP locale handling and the fact that setlocale() works per process (and not per thread). When PHP starts up, no locale is set from the enviroment (except for LC_TYPE). Only if a user explicitly calls setlocale() with the second argument not equal to "0", the locale is changed from C to whatever has been chosen and is available. Now consider a multi-threaded environment, which is rather common on Windows. While it is possible to set the desired locale immediately before the float to string conversion, it is not easily possible in PHP to make that really thread-safe. This makes it very hard to write robust code for these environments. Even if thread-safety is not an issue, a program that worked fine for years may be subtly broken by inserting a call to setlocale() somewhere. This “spooky action at a distance” could also “have their unit tests crash and burn and their data pipelines blow up”. [1] <http://news.php.net/php.internals/103639> -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
