Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109282
MIME-Version: 1.0
References: <CAH5C8xVoH-OmApcSF59eiUZye_aME1xiFs=umXEXLEG+pnjs8Q@mail.gmail.com>
 <CANS-=pdqvmsYXTLHHvm6VSdS+k0_q9QLKYV_oodH+cOEPjK8nw@mail.gmail.com>
 <CAFPFaMKmrk_94wixE231x155RghR+ta2dmQu=VCccW9xHaNJ7A@mail.gmail.com>
 <CANS-=pcK5kgHtRQxLEGA+4D3Sqm3p1KCeJyz32vvXCYJgj9MGw@mail.gmail.com> <CAH5C8xVUx5WfNGCU5ZThHosuCGPzk_9rmbAQ4A5KY4mXv1_7LA@mail.gmail.com>
In-Reply-To: <CAH5C8xVUx5WfNGCU5ZThHosuCGPzk_9rmbAQ4A5KY4mXv1_7LA@mail.gmail.com>
Date: Wed, 25 Mar 2020 09:25:49 +0100
Message-ID: <CANS-=pf-Rhi=nY_VzUeykEV7F-iGWstbwP=wUmdZ+r1Nm4tjsA@mail.gmail.com>
To: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>
Cc: "G. P. B." <george.banyard@gmail.com>, Nikita Popov <nikita.ppv@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000029761b05a1a99f90"
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Locale-independent float to string cast
From: kjarli@gmail.com (Lynn)

--00000000000029761b05a1a99f90
Content-Type: text/plain; charset="UTF-8"

I'm very sorry, I pressed the reply instead of reply all button, I hope
this fixes it!

I agree that these cases can go horribly wrong. However, my reasoning is
> the following:
> - if a piece of code currently relies on locale-independence (e.g.
> automated data exports) then this
> change wouldn't cause any breakage since a workaround has already been in
> place there (e.g. the
> programmers use var_export() instead of casting)
> - if a piece of code relies on the locale-dependent string representation
> of floats then there will be
> a BC break, sure, however I believe that code isn't very sensitive to the
> change in the vast majority of the
> cases since that data is for presentation purposes only.
>

I know it's for presentation purpose only, sadly it's not used for just
presentation code. It's being consumed and parsed by automated imports that
expect a format different than `3.5`, because that's how it organically
evolved. Even when it was meant only for presentation, the consumer
expected the `3,5` format and will keep expecting this until we notify them
of a change (and then it will probably still take weeks before this is
fixed on their side). A lot of code that I've encountered is stuff like:
```
$csv .= $product->getPrice() . ';';

// older code I've seen come by
$product = get_product($$var5);
$csv .= $product['price'] . ';';
```
As much as I'd like to see this fixed and always give a `3.5`, sadly that's
not the case if you use a different locale. Going through thousands of
files to fix this, is not going to be an easy task, especially not as this
is often old enough to not be usable by static code analyzers.


> Or do you have other locale-dependent use-cases in mind? I am sure there
> are some but I think the number of the situations where the change is
> problematic is less than what it first seems.
>

No, this is the only issue I personally see with it. However, the impact
could be severe enough to not be able to upgrade to a new PHP version in
the foreseeable future, thus I would like to see an upgrade path, one that
tells you where it would've gone wrong, instead of turning the behavior on
or off. If I can gather the logs and thus find usages, I can pro-actively
start fixing where this would go wrong. I'll take a performance hit over a
breakage. Performance penalty would only have to apply if the locale is set
to something we know will change the outcome. Maybe it turns out this is a
small issue, maybe it's a big issue... I can't tell because it's either
upgrade & break, or upgrade & work in the proposed scenario. Some breakage
may take weeks to find out because scripts run periodically.

I fully understand that you don't see this as a big issue, and I really
wish I could say the same. I can't vote, so I can't change the outcome,
please consider my use-case when moving forward, thanks!

Regards,
Lynn

--00000000000029761b05a1a99f90--