Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118484
MIME-Version: 1.0
References: <CANMwmbN8_Km+urXbNO7oWvNteYA2mTPNYyRgfaoypEK1Cw4F0A@mail.gmail.com>
 <CA+p1FaZDm3-h_LoOwv619wFyPg+2pAM8qC2La438sU_SPHZnCg@mail.gmail.com>
In-Reply-To: <CA+p1FaZDm3-h_LoOwv619wFyPg+2pAM8qC2La438sU_SPHZnCg@mail.gmail.com>
Date: Fri, 26 Aug 2022 06:47:45 +0200
Message-ID: <CABdc3WqsDc+80ATdX9+qstOkf+eUYCAQNPeV_FXcHiFumVQb8A@mail.gmail.com>
To: David Gebler <davidgebler@gmail.com>
Cc: juan carlos morales <dev.juan.morales@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000007f98505e71d9e06"
Subject: Re: [PHP-DEV] RFC json_validate() - status: Under Discussion
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=)

--00000000000007f98505e71d9e06
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

czw., 25 sie 2022, 21:12 u=C5=BCytkownik David Gebler <davidgebler@gmail.co=
m>
napisa=C5=82:

> I'm not a voter on RFCs so my input may be largely irrelevant here but fo=
r
> discussion purposes:
>
> I remain unconvinced regarding the justification for this proposal. I'm n=
ot
> saying there's a strong reason to NOT implement it, but I'm not convinced
> it's really going to be a significant benefit to many people at all.
>
> I agree that the number of userland implementations for a "is_valid_json"
> type function including in some widely used frameworks and systems
> indicates there's some degree of demand in the ecosystem for validating a
> JSON string.
>
> But the more salient question is whether there is a significant demand fo=
r
> whatever memory and speed benefit the implementation of a new core ext_js=
on
> function delivers; that is, has it been established that the use of
> json_decode or common userland solutions are in practice not good enough?
>
> There are many examples of userland code which could be faster and more
> memory efficient if they were written in C and compiled in, so the mere
> fact this proposal may introduce a somewhat faster way of validating a JS=
ON
> string over decoding it is not necessarily a sufficient reason to include
> it.
>
> Are there are examples of raising issues for frameworks or systems saying
> they need to validate some JSON but the only existing solutions available
> to them are causing memory limit errors, or taking too long? The Stack
> Overflow question linked on the RFC says "I need a really, really fast
> method of checking if a string is JSON or not."
>
> "Really, really fast" is subjective. No context or further information is
> given about what that person would regard as an acceptable time to valida=
te
> what size blob of valid or invalid JSON, or why. Indeed that same page
> offers a userland solution based around only going to json_decode if some
> other much simpler checks on the input are indeterminate for validation
> purposes. Haven't tested it personally but no doubt in the vast majority =
of
> cases it is sufficiently performant.
>
> In most real world use cases [that I've encountered over the years] JSON
> blobs tend to be quite small. I have dealt with much, much larger JSON
> blobs, up to a few hundred MB, and in those cases I've used a streaming
> parser. If you're talking about JSON that size, a streaming parser is the
> only realistic answer - you probably don't want to drop a 300MB string in
> to this RFC's new function either, if performance and memory efficiency i=
s
> your concern.
>
> So I'm curious as to whether a real world example can be given where the
> efficiency difference between json_decode and a new json_validate functio=
n
> would be important to the system, whether anyone's encountered a scenario
> where this would have made a real difference to them.
>

I share the same opinion you expressed here even though you admit in recent
email that you changed your mind.

In recent versions we tend to accept more and more small standard library
functions with IMO questionable argumentation. The same goes here and I'm
not convinced we should introduce next small function that can be simply
implemented in user land.

Any example testing > 3MB JSON string are for me edge cases that normally
don't happen often to deserve special treatment.

If we keep the tendency to pollute already bloated standard library with an
army of small functions that could have not exists and be replaced with
normal PHP counterparts IMHO we'll end with frustration from developers as
I believe DX slowly falls down here.

Cheers,
Micha=C5=82 Marcin Brzuchalski

>

--00000000000007f98505e71d9e06--