Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86388
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.173 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
In-Reply-To: <CAEKnhAF5eQQeQSDXr++OT=8mcrpAKuT2HGxFRYpr_x3eZPY=mA@mail.gmail.com>
Date: Mon, 25 May 2015 22:02:43 +0300
Cc: PHP internals list <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <07B2A0A0-9FF5-44B6-B5BA-42A5EF4463AE@gmail.com>
References: <CAEKnhAFxpRojbZBdH74pCaJfmFNDyZszyNanuTK3zSjsYtoBmg@mail.gmail.com> <5E3BAD6C-BC6B-4BBC-92E5-37AD7A6891E0@gmail.com> <CAEKnhAF5eQQeQSDXr++OT=8mcrpAKuT2HGxFRYpr_x3eZPY=mA@mail.gmail.com>
To: Jakub Zelenka <bukka@php.net>
Subject: Re: [PHP-DEV] [RFC] JSON number to string
From: indeyets@gmail.com (Alexey Zakhlestin)


> On 25 May 2015, at 18:40, Jakub Zelenka <bukka@php.net> wrote:
>=20
>> Anyway, as I told in a previous thread, while approach of this rfc =
solves immediate problem, it is not future-proof flexible and exposing =
low-level type based parsing is a better idea
>>=20
> IIRC your initial proposal was about converting everything to objects =
which is not flexible at all as it suffers exactly from the same =
problems as this RFC. The only difference is using object instead of =
string. I think that the above is much more flexible...
>=20
> However as I said before it is quite a big feature that could be done =
only in the minor version and requires considerably more time for =
implementation.

The difference is, that object would preserve type information from the =
document. Source representation would always be the string, but you will =
be able to know if it was typed as a Number or as a literal String. =
After that, application=E2=80=99s logic can decide what it should do =
with it.

But yeah, sure, that is a bigger feature

=D0=90.