Juan,
You can always offer two votes on the RFC - one for the function itself,
then one for should it return boolean or return an int representing the
json_last_error constants and let it be decided that way.
I think on the whole, I agree with the sentiment that returning boolean and
checking json
OMG, I need to take a rest, sorry for this, here it goes again; the
about JSON_INVALID_UTF8_IGNORE opinion is the same, but previous code
was wrong
Code:
string(5) "dummy" }
string(8) "No error"
Saying so, now ... yes I support and think is NEEDED the usage of the
JSON_INVALID_UTF8_IGNORE , as
El sáb, 27 ago 2022 a las 1:31, juan carlos morales
() escribió:
>
> === Open issues/concerns ===
>
>
> @@@ Usage of JSON_INVALID_UTF8_IGNORE @@@
>
> - I have my doubts now, because of this codes:
>
> ```
>
> var_dump(json_validate("\"a\xb0b\""), json_last_error_msg());
> var_dump("");
I now provide an update of the discussion.
The good, the bads, the open questions, etc.
All of this will go into the RFC also, as requested by the procedure
in https://wiki.php.net/rfc/howto
"Listen to the feedback, and try to answer/resolve all questions.
Update your RFC to document all the iss
On Fri, Aug 26, 2022, at 1:41 PM, Ayesh Karunaratne wrote:
>> whether returning boolean is the right thing to do at all. It seems obviously
>> intuitive it should, returning true for valid and false for invalid JSON
>> but then if you consider you're still going to be in the situation of
>> calling
On 25 August 2022 16:06:48 BST, "Tim Düsterhus" wrote:
>- I've noticed that 'unserialize()' already emits E_WARNING for some types of
>error (e.g. out-of-bounds integers), so users already need to be prepared for
>E_WARNING to be emitted. I've adjusted the aforementioned Notice to Warning,
>but
On 26 August 2022 18:28:59 BST, Kamil Tekiela wrote:
>What is the reasoning behind the name? I can't find it explained in the
>RFC. What about other alternatives like is_json or validate_json?
It's part of the json extension so it should start with json_ following naming
guidelines for functions
> whether returning boolean is the right thing to do at all. It seems obviously
> intuitive it should, returning true for valid and false for invalid JSON
> but then if you consider you're still going to be in the situation of
> calling json_last_error() if you want to know why invalid JSON was inv
On Fri, Aug 26, 2022 at 6:29 PM Kamil Tekiela wrote:
> What is the reasoning behind the name? I can't find it explained in the
> RFC. What about other alternatives like is_json or validate_json?
>
The name json_validate makes most sense to me; it groups itself together
nicely with the other json
What is the reasoning behind the name? I can't find it explained in the
RFC. What about other alternatives like is_json or validate_json?
On Fri, Aug 26, 2022 at 11:53 AM Christian Schneider
wrote:
> Am 26.08.2022 um 18:28 schrieb Sara Golemon :
> > What I can see is two noble, but conflicting ideals:
> > 1/ sort() and ksort() should be consistent about their sorting
> algorithms.
> > I think we can all agree about that in the idea
Am 26.08.2022 um 18:28 schrieb Sara Golemon :
> What I can see is two noble, but conflicting ideals:
> 1/ sort() and ksort() should be consistent about their sorting algorithms.
> I think we can all agree about that in the ideal case, at least.
> 2/ Behavior within a minor release should be self-co
On Fri, Aug 26, 2022 at 7:19 AM Christoph M. Becker
wrote:
>
> On 26.08.2022 at 05:15, Go Kudo wrote:
>
> > In the actively supported version of PHP, `ksort()` has been modified to
> > include BC Break.
> >
> > https://github.com/php/php-src/issues/9296
> >
> > This may seem like an appropriate bu
On Fri, Aug 26, 2022, at 4:00 AM, Michał Marcin Brzuchalski wrote:
> A `json_decode()` is a substitute that IMO solves 99% of use cases.
> If I'd follow your logic and accept every small addition that handles 1% of
> use cases, somebody will raise another RFC
> for simplexml_validate_string or yam
Oh! My bad. Nice work! Cheers
El vie., 26 de agosto de 2022 16:51, Tim Düsterhus
escribió:
> Hi
>
> On 8/26/22 16:15, juan carlos morales wrote:
> > Seems like we Don't Have tests for the function or we should enhance the
> > existing ones. If We would Have proper tests the FIX would break it (a
Hi
On 8/26/22 16:15, juan carlos morales wrote:
Seems like we Don't Have tests for the function or we should enhance the
existing ones. If We would Have proper tests the FIX would break it (as I
Don't see tests in the fix itself).That is why I say so.
Various tests were adjusted in:
http
> -Original Message-
> From: juan carlos morales
> Sent: Thursday, August 25, 2022 12:02 PM
> To: PHP Internals List
> Subject: [PHP-DEV] RFC json_validate() - status: Under Discussion
>
> Hello.
>
> I am glad to present to you the RFC for json_validate() function.
>
> The code/impleme
Seems like we Don't Have tests for the function or we should enhance the
existing ones. If We would Have proper tests the FIX would break it (as I
Don't see tests in the fix itself).That is why I say so.
I Am not in my computer atm. I Will check this later
El vie., 26 de agosto de 2022 15:01,
Am 26.08.2022 um 14:19 schrieb Christoph M. Becker :
> On 26.08.2022 at 05:15, Go Kudo wrote:
>
>> In the actively supported version of PHP, `ksort()` has been modified to
>> include BC Break.
>>
>> https://github.com/php/php-src/issues/9296
>>
>> This may seem like an appropriate bug fix, but i
On 26.08.2022 at 01:29, Larry Garfield wrote:
> On Thu, Aug 25, 2022, at 3:16 PM, Rowan Tommins wrote:
>
>> But then we face the awkward asymmetry of the current functionality:
>>
>> intdiv() - Integer division
>> / - Floating-point division
>> % - Integer modulus
>> fmod() - Floating-point modulo
On 26.08.2022 at 05:15, Go Kudo wrote:
> In the actively supported version of PHP, `ksort()` has been modified to
> include BC Break.
>
> https://github.com/php/php-src/issues/9296
>
> This may seem like an appropriate bug fix, but it is a clear BC Break. I
> think this change should only be intro
El vie., 26 de agosto de 2022 13:08, juan carlos morales <
dev.juan.mora...@gmail.com> escribió:
>
> Is there a better way to do validation other than json_decode?
>
Better way than json_decode... Always from the core perspective
>
Just Want to remind that this discussion is not about "a json parser can be
written in PHP or not?".
We Have a JSON parser already in the core, ready to be use for validation.
Does it make sense to have another parser in User land to do validation if
We already have one?
Is there a better way to
Hi Tim,
pt., 26 sie 2022 o 12:15 Tim Düsterhus napisał(a):
> Hi
>
> On 8/26/22 11:14, Hans Henrik Bergan wrote:
> >> you can't efficiently validate JSON in userland
> >
> > Has anyone actually put that claim to the test? Has anyone actually made
> a
> > userland json validator (not just wrap jso
Hi
On 8/26/22 11:00, Michał Marcin Brzuchalski wrote:
A `json_decode()` is a substitute that IMO solves 99% of use cases.
If I'd follow your logic and accept every small addition that handles 1% of
use cases, somebody will raise another RFC
for simplexml_validate_string or yaml_validate and the
Hi
On 8/26/22 11:14, Hans Henrik Bergan wrote:
you can't efficiently validate JSON in userland
Has anyone actually put that claim to the test? Has anyone actually made a
userland json validator (not just wrap json_decode()/json_last_error()) for
performance comparison?
( if not, https://www.js
Hi
On 8/26/22 10:56, Paul Crovella wrote:
I'm for this as well. Though something more than a boolean is useful to
indicate when the max depth has been exceeded as that's not strictly a
problem with the json's validity.
Yes, it's not strictly invalid JSON, but I expect json_validate() to be
u
El vie, 26 ago 2022 a las 11:55, Peter Bowyer
() escribió:
>
> That's a good point which I had overlooked. Does an exception make most
> sense when this happens?
>
> Peter
I just got a code review from Derick Rethans explaining me that a
validation routine should not throw an exception.
I think i
On Fri, 26 Aug 2022 at 09:56, Paul Crovella wrote:
> I'm for this as well. Though something more than a boolean is useful to
> indicate when the max depth has been exceeded as that's not strictly a
> problem with the json's validity.
>
That's a good point which I had overlooked. Does an exceptio
El vie, 26 ago 2022 a las 11:43, Andreas Leathley
() escribió:
>
> On 26.08.22 11:00, Michał Marcin Brzuchalski wrote:
>
> There is already a way to validate XML in PHP, and Yaml or PHP is
> something within the control of a PHP programmer, while JSON is mostly
> used as a format for communication
El vie, 26 ago 2022 a las 11:35, Michał Marcin Brzuchalski
() escribió:
> Your examples are a couple of functions.
> Assuming that they're heavily used is as true as my assumptions.
>
> Cheers,
Is good you clarify that your numbers were assumptions.
By the way, I never said anything about how my
On 26.08.22 11:00, Michał Marcin Brzuchalski wrote:
A `json_decode()` is a substitute that IMO solves 99% of use cases.
If I'd follow your logic and accept every small addition that handles 1% of
use cases, somebody will raise another RFC
for simplexml_validate_string or yaml_validate and the nex
Hi Juan,
pt., 26 sie 2022 o 11:26 juan carlos morales
napisał(a):
> El vie, 26 ago 2022 a las 11:00, Michał Marcin Brzuchalski
> () escribió:
> >
> > A `json_decode()` is a substitute that IMO solves 99% of use cases.
> > If I'd follow your logic and accept every small addition that handles 1%
>
El vie, 26 ago 2022 a las 11:26, juan carlos morales
() escribió:
>
> How can you make such an assertion in those numbers (99% of use cases
> and son on, that you mention) ? Can you give us more information about
> this assertions?
>
> I have provide real examples where the need to validate-only a
El vie, 26 ago 2022 a las 11:00, Michał Marcin Brzuchalski
() escribió:
>
> A `json_decode()` is a substitute that IMO solves 99% of use cases.
> If I'd follow your logic and accept every small addition that handles 1% of
> use cases, somebody will raise another RFC
> for simplexml_validate_string
El vie, 26 ago 2022 a las 10:56, Paul Crovella
() escribió:
>
> I'm for this as well. Though something more than a boolean is useful to
> indicate when the max depth has been exceeded as that's not strictly a
> problem with the json's validity.
Thanks, seems to be good idea to take it out, and I w
El vie, 26 ago 2022 a las 10:28, Peter Bowyer
() escribió:
>
> Hi Juan,
>
> On Thu, 25 Aug 2022 at 17:02, juan carlos morales
> wrote:
>>
>> RFC: https://wiki.php.net/rfc/json_validate
>
>
> Thanks for bringing forward this RFC. I am in favour of this change, as you
> can't efficiently validate
quote
> you can't efficiently validate JSON in userland
Has anyone actually put that claim to the test? Has anyone actually made a
userland json validator (not just wrap json_decode()/json_last_error()) for
performance comparison?
( if not, https://www.json.org/JSON_checker/JSON_checker.c would p
Hi Dusk,
pt., 26 sie 2022 o 08:17 Dusk napisał(a):
> On Aug 25, 2022, at 21:47, Michał Marcin Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
> > The same goes here and I'm not convinced we should introduce next small
> function that can be simply implemented in user land.
>
> What "simple
On 8/26/2022 1:28 AM, Peter Bowyer wrote:
Hi Juan,
On Thu, 25 Aug 2022 at 17:02, juan carlos morales <
dev.juan.mora...@gmail.com> wrote:
RFC: https://wiki.php.net/rfc/json_validate
Thanks for bringing forward this RFC. I am in favour of this change, as you
can't efficiently validate JSON i
Hi Juan,
On Thu, 25 Aug 2022 at 17:02, juan carlos morales <
dev.juan.mora...@gmail.com> wrote:
> RFC: https://wiki.php.net/rfc/json_validate
Thanks for bringing forward this RFC. I am in favour of this change, as you
can't efficiently validate JSON in userland.
Like Rowan I'm not convinced JS
41 matches
Mail list logo
