Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105080
MIME-Version: 1.0
References: <40683e93-f8e9-5a8c-9646-31c73c99396f@fischer.name>
 <CAF+90c-cVBy=YaPVz5B2Ua26y_yBz5KRnx9BnjVGe6uHbsi2Bg@mail.gmail.com>
 <5ca53ea8.1c69fb81.d773b.1df3SMTPIN_ADDED_MISSING@mx.google.com>
 <CAG9XoMT76XZFx6fKPMea0rdJpb6JB1Yzr7mHc6e-E5W4-vL3RQ@mail.gmail.com>
 <CAHN63oOMHCVx-yMfJ57noAFGyW_yfnRbjc2hv04gWU+m6N1Fjw@mail.gmail.com> <CAG9XoMQ6nnF2Mn764JMNwLQ=PYDKPbVm+Ovq=tqL_JoRhqNeJA@mail.gmail.com>
In-Reply-To: <CAG9XoMQ6nnF2Mn764JMNwLQ=PYDKPbVm+Ovq=tqL_JoRhqNeJA@mail.gmail.com>
Date: Thu, 4 Apr 2019 09:15:30 -0700
Message-ID: <CAHN63oNO4k2CFYKxK5cseFUugmS7caMP8fjpn5UepiqzzJ641w@mail.gmail.com>
To: Benjamin Morel <benjamin.morel@gmail.com>
Cc: Andrea Faulds <ajf@ajf.me>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007b5a540585b6ae28"
Subject: Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings
From: mo.mu.wss@gmail.com ("M. W. Moe")

--0000000000007b5a540585b6ae28
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello,

Yes and No php has an existing echo-system of extensions which could not
work
without this ini model; therefor it's fashion trend which is in my opinion
unrealistic or you
are ready to break existing infrastructures.

Enforcing  the right behavior (third one) will break existing code big
time; hence at some point
you need to go with a transitional state; it does not say that one day
you'r not gonna retire it
and finally enforcing only one ((the right behavior (third one))).




On Thu, Apr 4, 2019 at 9:06 AM Benjamin Morel <benjamin.morel@gmail.com>
wrote:

> what about exposing a strict keyword option or a php ini option?
>
>
> There is a trend right now towards avoiding the language to be dependent
> on php.ini options. I'm on board with this, and would personally strongly
> discourage introducing such an option, and enforce one of these options f=
or
> everyone instead.
>
> On Thu, 4 Apr 2019 at 17:05, M. W. Moe <mo.mu.wss@gmail.com> wrote:
>
>> Hello,
>>
>> what about exposing a strict keyword option or a php ini option?
>>
>> - NO - leave as it is                            default
>> - YES - allow trailing whitespace       punks
>> - YES - disallow leading whitespace sane people
>>
>> On Thu, Apr 4, 2019 at 1:57 AM Benjamin Morel <benjamin.morel@gmail.com>
>> wrote:
>>
>>> What about going forward with the trailing whitespace RFC right now, bu=
t
>>> ask to vote between 3 options?
>>>
>>> - NO - leave as it is
>>> - YES - allow trailing whitespace
>>> - YES - disallow leading whitespace
>>>
>>> And then proceeding with the string to number comparison RFC?
>>>
>>> Ben
>>>
>>> On Thu, 4 Apr 2019 at 01:15, Andrea Faulds <ajf@ajf.me> wrote:
>>>
>>> > Nikita Popov wrote:
>>> > > I'm always a fan of making things stricter, but think that in this
>>> > > particular case there are some additional considerations we should
>>> keep
>>> > in
>>> > > mind.
>>> > >
>>> > > 1. What is more important to me here than strictness is consistency=
.
>>> > Either
>>> > > both "   123" and "123   " are numeric, or neither are. Making "123
>>>   "
>>> > > numeric is a change we can easily do, because it makes the numeric
>>> string
>>> > > definition more permissive and is thus mostly backwards compatible.
>>> Doing
>>> > > the reverse change is certainly not compatible and will be a much
>>> harder
>>> > > sell.
>>> > >
>>> > > 2. I believe that a large part of the motivation here is that by
>>> making
>>> > the
>>> > > numeric string definition slightly more lax (in a consistent
>>> manner), we
>>> > > can make *other* things more strict, because this essentially
>>> eliminates
>>> > > the only "somewhat reasonable" case of trailing characters. The RFC
>>> > already
>>> > > mentions two of them:
>>> > >
>>> > > a) We can hard reject "123foo" inputs to "int" arguments (and some
>>> other
>>> > > places). Currently this is allowed with a notice. I think if we
>>> resolve
>>> > the
>>> > > trailing whitespace question, then there cannot be any reasonable
>>> > > opposition to this change.
>>> > > b) My own RFC on number to string comparisons would benefit from
>>> this.
>>> > From
>>> > > initial testing it has surprisingly little impact, but one of the f=
ew
>>> > cases
>>> > > that turned up was this comparison with a string that had trailing
>>> > > whitespace.
>>> > >
>>> > > Personally I think both of those changes are a lot more valuable
>>> than a
>>> > > stricter numeric string definition without leading/trailing
>>> whitespace.
>>> >
>>> > I'm kinda unsure how to go forward because of these points. I would
>>> like
>>> > to see improved comparisons, and I would like to see the end of the
>>> > =E2=80=9Cnon-well-formed=E2=80=9D numeric string, and I think this wh=
itespace RFC could
>>> > be helpful to both. But I can't see the future, I don't know whether
>>> > people will vote for removing leading or permitting traiing whitespac=
e
>>> > and whether or not they will be influenced by or this will influence
>>> > opinion on the further improvements. =C2=AF\_(=E3=83=84)_/=C2=AF
>>> >
>>> > I'm torn between:
>>> >
>>> > * Vote on allowing trailing whitespace
>>> > * Vote on disallowing leading whitespace
>>> > * Vote on which of those two approaches to go for
>>> > * Trying to bundle everything together and voting on it as a package.
>>> >
>>> > I'm probably thinking too strategically.
>>> >
>>> > Andrea
>>> >
>>> > --
>>> > PHP Internals - PHP Runtime Development Mailing List
>>> > To unsubscribe, visit: http://www.php.net/unsub.php
>>> >
>>> >
>>>
>>

--0000000000007b5a540585b6ae28--