Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103655
To: Stanislav Malyshev <smalyshev@gmail.com>, internals@lists.php.net
References: <a7761c2f-5716-279b-d701-5f588b856277@gmx.de>
 <dbfae3d5-e317-f680-9fe6-240ab142d105@gmail.com>
Message-ID: <94f5feb8-6589-3a0a-2849-7679cec1858c@gmx.de>
Date: Mon, 31 Dec 2018 00:25:41 +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: <dbfae3d5-e317-f680-9fe6-240ab142d105@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Inconsistent float to string vs. string to floatcasting
From: cmbecker69@gmx.de ("Christoph M. Becker")

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