El sáb, 30 jul 2022 a las 8:30, Dusk () escribió:
> On Jul 29, 2022, at 23:05, Aleksander Machniak wrote:
> > json_decode() has $depth argument, I think is_json() probably also
> should. And I'm not sure about JSON_INVALID_UTF8_IGNORE flag.
> >
> > My point is that if you use these with json_deco
Just want to clarify that when I mentioned the use of memory, I wrote down
the function "memory_get_usage()", which basically gives us the memory
handle by php that is related to the memory_limit INI setting.
Now I will provide a benchmark I have done really quick:
# Code used (I have the impleme
On Jul 29, 2022, at 23:05, Aleksander Machniak wrote:
> json_decode() has $depth argument, I think is_json() probably also should.
> And I'm not sure about JSON_INVALID_UTF8_IGNORE flag.
>
> My point is that if you use these with json_decode() you might also need to
> use these with is_json()
On 29.07.2022 16:26, juan carlos morales wrote:
is_json(string $string): bool
json_decode() has $depth argument, I think is_json() probably also
should. And I'm not sure about JSON_INVALID_UTF8_IGNORE flag.
My point is that if you use these with json_decode() you might also need
to use the
On Fri, Jul 29, 2022 at 7:27 AM juan carlos morales <
dev.juan.mora...@gmail.com> wrote:
> # Why this function ?
>
> At the moment the only way to determine if a JSON-string is valid we have
> to execute the json_decode() function.
>
> The drawback about this, is that json_decode() generates an in
El vie, 29 jul 2022 a las 22:18, David Rodrigues ()
escribió:
> I was about to say NO, but after being completely your argument, the idea
> makes sense.
>
> Initially I thought about using json_decode() with error capture, but the
> idea that it would overload memory makes perfect sense, compared
I was about to say NO, but after being completely your argument, the idea
makes sense.
Initially I thought about using json_decode() with error capture, but the
idea that it would overload memory makes perfect sense, compared to a
simple structure analysis, if that is indeed the user's intention.
Hi Juan,
pt., 29 lip 2022, 16:26 użytkownik juan carlos morales <
dev.juan.mora...@gmail.com> napisał:
> I am following the RFC guideline for the first time. (
> https://wiki.php.net/rfc/howto)
>
> As suggested there, I am here to get a feeling from you, regarding the
> following RFC for PHP.
>
>
Hi!
I'm currently in the process of cleaning up the error handling of the
new ext/random and now came across the implementation of __unserialize().
Looking through the source code for existing examples I found that the
following is used:
- ext/gmp: Exception
- ext/hash: Exception
- ext/date
I am following the RFC guideline for the first time. (
https://wiki.php.net/rfc/howto)
As suggested there, I am here to get a feeling from you, regarding the
following RFC for PHP.
# Change (draft):
New function in php called like:
is_json(string $string): bool
## Description
### Parameters
st
>1. Are there any reasonable objections to consistently implementing
character range expressions for all character masks?
would be a minor BC break to silently change the meaning of memspn($str,
"a..b"), which currently has the same meaning as "a.b" with wasted cpu
cycles, but with your suggestion
On Fri, Jul 29, 2022 at 7:15 AM mickmackusa wrote:
>
>
> On Monday, July 25, 2022, Guilliam Xavier
> wrote:
>
>> On Sat, Jul 9, 2022 at 1:56 AM mickmackusa wrote:
>>
>>> I've discovered that several native string functions offer a character
>>> mask
>>> as a parameter.
>>>
>>> I've laid out my
12 matches
Mail list logo
