On Tue, 23 Aug 2022 at 19:09, David Gebler wrote:
> I can just see floor_div and floor_mod getting mixed up
> with fdiv and fmod but maybe I'm overthinking it, maybe it wouldn't really
> be an issue. Maybe there's alternative names you could give them though
> again I suspect the ones you've chos
Hi
On 8/1/22 14:58, G. P. B. wrote:
- Add a new UnserializationFailureException extends Exception (or
whatever color the bikeshed should have). Any existing catch blocks
should still match, as Exception is more general. It would break for
ext/spl, though. Unless UnserializationFailureException e
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:
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
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'
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
Thanks for participating. Cheers.
RFC: https://wiki.php.net/rfc/json_validate
Implementation: https://github.com/php/php-src/pull/9399
On 25/08/2022 12:33, Peter Bowyer wrote:
Is this not one time where using a flag to change a function's behaviour
makes sense? So rather than fdiv, floor_div, int_div (etc) we have div($1,
$2, DIV_FLOAT), div($1, $2, DIV_FLOOR), div($1, $2, DIV_INT).
I'm not proposing div (non namespaced) as t
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
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
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
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
[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
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
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
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
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
>
> Apparently as of PHP 8.0, there is also an fdiv() f
> 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
Hi Internals.
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 introduced in PHP 8.2 and later.
Fortunat
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
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()
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
22 matches
Mail list logo
