AFAIK, gettext functions do depend on setlocale.
I wish so much that it wasn't the case (as you then need to have the
locale installed on the system), but it is, so setlocale definetely is
quite used in the wild and deprecating it seems a bit far-fetched
unless we can actually replace it with
On 03.01.2019 at 02:19, Stanislav Malyshev wrote:
> If this is part of a data pipeline, the difference between 1,500 and
> 1.500 can be huge (about 1000 times ;). With luck, there would be unit
> tests, so instead of broken bank account we'd have broken unit tests,
> but we all know how unit test
On 02.01.2019 at 16:51, Zeev Suraski wrote:
> If we do end up adding a new INI entry - maybe it can be a tristate -
> legacy, legacy+notice, or new. Just a thought. And I wouldn’t commit to
> actually removing it at any time by officially deprecating it...
I have some doubts that an INI
Hi,
Am 03.01.2019 um 10:21 schrieb Zeev Suraski:
On Wed, Jan 2, 2019 at 8:57 PM Nikita Popov 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
On Thu, Jan 3, 2019 at 3:30 PM Rowan Collins
wrote:
> On Thu, 3 Jan 2019 at 09:21, Zeev Suraski wrote:
>
> >
> > I agree, but the real question is how many of those who are explicitly
> > calling setlocale() are relying on this behavior
> >
>
>
> It occurs to me that we could ask the opposite
On Thu, 3 Jan 2019 at 09:21, Zeev Suraski wrote:
>
> I agree, but the real question is how many of those who are explicitly
> calling setlocale() are relying on this behavior
>
It occurs to me that we could ask the opposite question: what *other*
reasons do people have for explicitly calling
On Wed, Jan 2, 2019 at 8:57 PM Nikita Popov wrote:
> 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
Hi!
> 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
On 2019-01-02 19:22, Zeev Suraski wrote:
1. I'm not sure what you mean "not many people use this"? People don't
convert floats to strings?
People don't format their floats using setlocale + echo. People use
things like sprintf and number_format to get the right number of
decimals, and many
On Wed, Jan 2, 2019 at 6:22 PM Zeev Suraski wrote:
>
>
> On Wed, Jan 2, 2019 at 6:11 PM Nikita Popov wrote:
>
>> On Wed, Jan 2, 2019 at 12:33 PM Zeev Suraski 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
On Wed, Jan 2, 2019 at 6:11 PM Nikita Popov wrote:
> On Wed, Jan 2, 2019 at 12:33 PM Zeev Suraski 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
On Wed, Jan 2, 2019 at 12:33 PM Zeev Suraski wrote:
>
>
> On Wed, Jan 2, 2019 at 11:26 AM Nikita Popov wrote:
>
>> On Wed, Jan 2, 2019 at 12:30 AM Stanislav Malyshev
>> wrote:
>>
>> We have a rather hard policy against ini options that influence language
>> behavior. Locale-dependent language
On Wed, 2 Jan 2019 at 17:12 Christoph M. Becker wrote:
> On 02.01.2019 at 12:32, Zeev Suraski wrote:
>
> > Unless I'm missing something, changing this behavior would require a
> full,
> > line-by-line audit of the code - with no Search & Replace patterns that
> can
> > find these instances in
On 02.01.2019 at 12:32, Zeev Suraski wrote:
> On Wed, Jan 2, 2019 at 11:26 AM Nikita Popov wrote:
>
>> On Wed, Jan 2, 2019 at 12:30 AM Stanislav Malyshev
>> wrote:
>>
>> We have a rather hard policy against ini options that influence language
>> behavior. Locale-dependent language behavior is
On Wed, Jan 2, 2019 at 11:26 AM Nikita Popov wrote:
> On Wed, Jan 2, 2019 at 12:30 AM Stanislav Malyshev
> wrote:
>
> We have a rather hard policy against ini options that influence language
> behavior. Locale-dependent language behavior is essentially the same issue,
> just worse due to the
On 01/01/2019 23:29, Stanislav Malyshev wrote:
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
That's part of locale being global.
On Wed, Jan 2, 2019 at 12:30 AM Stanislav Malyshev
wrote:
> Hi!
>
> > So yes, (string)0.3 should return 0.3 in any locale.
>
> If we designed it now, without any doubt. But since we have 20 years of
> history behind... I'm not so sure.
>
> > Finally, I don't think that the global locale is the
Hi!
> So yes, (string)0.3 should return 0.3 in any locale.
If we designed it now, without any doubt. But since we have 20 years of
history behind... I'm not so sure.
> 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
On 31.12.2018 at 00:25, Christoph M. Becker wrote:
> 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.
Nonsense. There's nothing wrong with
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
20 matches
Mail list logo
