The RFC got accepted and merge. Thanks for contributing :)
Don't think it makes a difference to the discussion at this point but just
thought I'd point out there's another example missing from the RFC list
that almost everyone probably has installed with their projects.
https://github.com/sebastianbergmann/phpunit/blob/main/src/Framework/Constraint/String
The RFC is in voting phase now.
I want to thank everyone involved in the discussions related to this
RFC, the ones who reviewed the code in advance, and the ones that with
some emojis in github showed their interest and support.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscr
Hi
On 9/20/22 00:15, juan carlos morales wrote:
The RFC still contains a non-empty "Open Issues" section. This needs to
be resolved before the vote starts.
I would also recommend inserting a closed voting widget (or multiple, if
you want to have additional votes for the details), so that it's c
> The RFC still contains a non-empty "Open Issues" section. This needs to
> be resolved before the vote starts.
>
> I would also recommend inserting a closed voting widget (or multiple, if
> you want to have additional votes for the details), so that it's clear
> for everyone how exactly the vote w
Hi
On 9/19/22 23:26, juan carlos morales wrote:
It appears the discussion came to a halt. How do you plan to proceed
with your RFC?
Thanks for the heads up email Tim.
People, following the procedure, this is a "heads up" email to all of
you regarding this RFC. If no significant issue/complain
> It appears the discussion came to a halt. How do you plan to proceed
> with your RFC?
Thanks for the heads up email Tim.
People, following the procedure, this is a "heads up" email to all of
you regarding this RFC. If no significant issue/complain raises, then
I will move the RFC for voting by
Hi
On 8/25/22 18:02, juan carlos morales wrote:
I am glad to present to you the RFC for json_validate() function.
It appears the discussion came to a halt. How do you plan to proceed
with your RFC?
Best regards
Tim Düsterhus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubs
El lun, 29 ago 2022 a las 11:26, Deleu () escribió:
>
>
>
> On Mon, Aug 29, 2022 at 11:19 AM juan carlos morales
> wrote:
>>
>> El lun, 29 ago 2022 a las 11:06, Deleu () escribió:
>> >
>> > Has the option of returning a Result object been discussed/considered? Can
>> > it be an option? I imagine
El lun, 29 ago 2022 a las 11:06, Deleu () escribió:
>
> Has the option of returning a Result object been discussed/considered? Can it
> be an option? I imagine that if `json_validate(): JsonValidationResult`
> always returns a `JsonValidationResult` which contains a `public readonly
> bool $vali
On Mon, Aug 29, 2022 at 10:50 AM juan carlos morales <
dev.juan.mora...@gmail.com> wrote:
> There is still 1 open question on the RFC, and is about the return value.
>
> https://wiki.php.net/rfc/json_validate#open_issuesquestions
>
> I would appreciate your feedback on this. Even though I was told
There is still 1 open question on the RFC, and is about the return value.
https://wiki.php.net/rfc/json_validate#open_issuesquestions
I would appreciate your feedback on this. Even though I was told the
RFC can go with 2 votings, I would like to know your thoughts about
that open question, in sho
El sáb, 27 ago 2022 a las 2:50, David Gebler () escribió:
>
> 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.
Thanks for the advice I di
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 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 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
> -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_validat
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
El vie, 26 ago 2022 a las 6:47, Michał Marcin Brzuchalski
() escribió:
>
>
> 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 questiona
On Aug 25, 2022, at 21:47, Michał Marcin Brzuchalski
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 implementation in userland" do you have in mind? Can you provide
an example?
json_decode()
czw., 25 sie 2022, 21:12 użytkownik David Gebler
napisał:
> I'm not a voter on RFCs so my input may be largely irrelevant here but for
> discussion purposes:
>
> I remain unconvinced regarding the justification for this proposal. I'm not
> saying there's a strong reason to NOT implement it, but I
> Having actually compiled the branch and tried it out, I have to say
> regardless of whether validating arbitrarily large blocks of JSON without
> being interested in the contents is a common or more niche use case, the
> memory savings ARE highly impressive. I had thought that because the func
Having actually compiled the branch and tried it out, I have to say
regardless of whether validating arbitrarily large blocks of JSON without
being interested in the contents is a common or more niche use case, the
memory savings ARE highly impressive. I had thought that because the
function was bu
I also added in the RFC your concern about JSON_THROW_ON_ERROR usage.
RFC: https://wiki.php.net/rfc/json_validate
Implementation: https://github.com/php/php-src/pull/9399
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Ok then ... I take it out of the RFC just because we have doubts about it.
RFC: https://wiki.php.net/rfc/json_validate
Implementation: https://github.com/php/php-src/pull/9399
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[Replying to list - make sure to hit "Reply List" or "Reply All", not
"Reply" in your mail client]
On 25/08/2022 21:59, juan carlos morales wrote:
Hello Rowan thanks for participating.
My answer for your comments would be:
=== Regarding JSON_THROW_ON_ERROR ===
I think is a valid point from yo
Hey Tim, thanks a lot for participating and taking your time to use
the code and making your own tests, I highly appreciate it.
Regards.
RFC: https://wiki.php.net/rfc/json_validate
Implementation: https://github.com/php/php-src/pull/9399
--
PHP Internals - PHP Runtime Development Mailing List
Hello Rowan thanks for participating.
My answer for your comments would be:
=== Regarding JSON_THROW_ON_ERROR ===
I think is a valid point from your side, and I am open to change the
implementation if the maintainers believe so. I leave it there as it
existed in json_decode() and wanted to give t
On 25/08/2022 17:02, juan carlos morales wrote:
I am glad to present to you the RFC for json_validate() function.
RFC: https://wiki.php.net/rfc/json_validate
Hi,
Leaving aside the overall question of inclusion and looking at details,
I'm not convinced JSON_THROW_ON_ERROR belongs here.
Wit
Hi
On 8/25/22 21:11, David Gebler wrote:
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 JSON
string over decoding it is not nece
Thanks for participating. Cheers.
RFC: https://wiki.php.net/rfc/json_validate
Implementation: https://github.com/php/php-src/pull/9399
Hello David, thanks for your feedback.
I believe that the answer to most of your concerns/questions related to
other projects that would benefit out of something like this is already
answered by me in the RFC. I mentioned major PHP projects that will
directly benefit out of something like this.
A
On Thu, Aug 25, 2022, 9:12 PM David Gebler wrote:
>
> 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.
>
I don'
I'm not a voter on RFCs so my input may be largely irrelevant here but for
discussion purposes:
I remain unconvinced regarding the justification for this proposal. I'm not
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 man
Hello.
I am glad to present to you the RFC for json_validate() function.
The code/implementation still needs some workout, but seems to be fine
enough to be presented to you all.
I look forward for feedback
Thanks in advance.
Juan.
RFC: https://wiki.php.net/rfc/json_validate
Implementation:
61 matches
Mail list logo
