Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103670
MIME-Version: 1.0
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>
In-Reply-To: <CAJHtznwkU5nt3hPrE7f8X+cND3F6OMxTaFGBUZ6=Of_+rB0tsQ@mail.gmail.com>
Date: Wed, 2 Jan 2019 19:56:46 +0100
Message-ID: <CAF+90c-UdKJnM17uNXK51sHOYUdM+9BCtpofsBMz_8rBcUPM=Q@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, "Christoph M. Becker" <cmbecker69@gmx.de>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000032d46c057e7e36b9"
Subject: Re: [PHP-DEV] Inconsistent float to string vs. string to floatcasting
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000032d46c057e7e36b9
Content-Type: text/plain; charset="UTF-8"

On Wed, Jan 2, 2019 at 6:22 PM Zeev Suraski <zeev@php.net> wrote:

>
>
> On Wed, Jan 2, 2019 at 6:11 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
>> On Wed, Jan 2, 2019 at 12:33 PM Zeev Suraski <zeev@php.net> wrote:
>> I don't expect this to be a particularly large issue for two reasons:
>>
>> 1. Not many people use this. I'm sure that there *are* people who use
>> this and use it intentionally, but I've only ever seen reference to this
>> issue as a bug or a gotcha.
>> 2. Even if somebody is using this functionality, the only thing that's
>> going to happen is that their number display switches from 1,5 to 1.5.
>> That's a minor UX regression, not a broken application. It's something that
>> will have to be fixed, but it's also not critical, and for a legacy
>> application one might even not bother.
>>
>
> FWIW, neither of these are very convincing for me:
> 1. I'm not sure what you mean "not many people use this"?  People don't
> convert floats to strings?
>

No, that's not what I meant. Of course, many people convert floats to
strings. But the vast majority of them expect to get back a floating point
number in the standard format.

What I mean is that there are not many people who use float to string
conversion with the express intention of receiving a locale-dependent
result (and use a locale where the question is relevant). Those are the
only people who would be (negatively) affected by such a change.


> 2. Perhaps you meant they weren't proactively relying on this behavior,
> which could be true - but it doesn't matter whether people were expecting
> or otherwise desiring this behavior when they wrote the code.  Whatever the
> current behavior is - they adjusted for it, and ended up using it,
> consequently relying on it.
>

As said, I'm sure there are people relying on this. What I'm saying is that
the number of people who rely on float conversions to *not* be
locale-sensitive is vastly, orders of magnitudes larger than the number of
people who *do* rely on it being locale sensitive.

The only saving grace is that this issue only turns up relatively rarely,
because it requires you to explicitly call setlocale, as the locale is not
inherited from the environment. Or more likely, you're not going to call
setlocale, but discover this wonderful behavior because something else does
for entirely unrelated reasons.


> 3. I view a UX change as a big deal.  As we should in a language that is
> very commonly used to create UI.
> 4. This could effect not only UX, but also integration code.  You could
> have PHP output feeding into something else - and suddenly, the format
> breaks.  With the fix HAVING to be in the other side, no less.
>

The fix doesn't have to be on the other side. Most likely you'd prefer to
fix it on your side by explicitly formatting the float in the desired
manner.

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.

Nikita

--00000000000032d46c057e7e36b9--