Re: [PHP-DEV] Follow up to "The death of `#ifndef FAST_ZPP`?"

On Sep 15, 2016 7:10 AM, "Andrea Faulds" wrote: > > Hi Pierre, > > > Pierre Joye wrote: >> >> >> Thanks you :) >> >> Please add this note to UPGRADING.INTERNALS as well : > > > Well, I was wondering about that, but I don't really know where it should be noted. > > It's not a

Re: [PHP-DEV] Follow up to "The death of `#ifndef FAST_ZPP`?"

Hi Pierre, Pierre Joye wrote: Thanks you :) Please add this note to UPGRADING.INTERNALS as well : Well, I was wondering about that, but I don't really know where it should be noted. It's not a user-facing change, in fact nobody was disabling FAST_ZPP anyway, so it couldn't be one.

Re: [PHP-DEV] Directly embed small strings in zvals

Hi Dmitry, Dmitry Stogov wrote: I was skeptical about this idea, but the PoC looks interesting and quite simple. This might be too big change for 7.*, if we won't completely hide implementation details for extensions using existing macros... I've wondered about 7.x. You can't *completely*

[PHP-DEV] GOOD Benchmark Results for PHP Master 2016-09-15

Results for project PHP master, build date 2016-09-14 06:25:07+03:00 commit: 494c5dc previous commit:409ff32 revision date: 2016-09-14 01:01:19+02:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

Re: [PHP-DEV] Directly embed small strings in zvals

Hi Dmitry, Andrea Faulds wrote: One nice thing, though, is that the API itself doesn't really change, you just have to be more careful about how you use it. So, optimistically, breakage might be quite small. I don't know how much breakage there is currently. Sorry, I made a mistake here, I

Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness

Hi Kazuo, On Thu, Sep 15, 2016 at 3:17 AM, Kazuo Oishi wrote: >> I updated the RFC. >> 2nd parameter (more_entropy) is int now. >> >> - 0 for disable more entropy. >>(Compatible with current $more_entropy=FALSE) >> - 1 for 10 digits entropy. e.g. 1.23456789 >>

Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness

Hi, > I updated the RFC. > 2nd parameter (more_entropy) is int now. > > - 0 for disable more entropy. >(Compatible with current $more_entropy=FALSE) > - 1 for 10 digits entropy. e.g. 1.23456789 >(Compatible with current $more_entropy=TRUE) DEFAULT > - 13 to 255 to number of entropy

[PHP-DEV] Super-types declaration

There are a RFC for union-types (https://wiki.php.net/rfc/union_types) that was declined, but I see that it is a recurring question here (today, for instance, David Eddy tried to start this discussion again with the same concept). Then, I don't know if the problem is the union methodology like

Re: [PHP-DEV] RFC - Immutable classes

Sent from my Alcatel Onetouch Idol 3 (4.7) On Sep 14, 2016 7:08 PM, Fleshgrinder wrote: > > On 9/13/2016 11:38 PM, Mathieu Rochette wrote: > > I agree that blocking clone seems unnecessary. I also don't see why it > > is useful to have "clone" methods. Why not let

Re: [PHP-DEV] RFC - Immutable classes

On 9/13/2016 11:38 PM, Mathieu Rochette wrote: > I agree that blocking clone seems unnecessary. I also don't see why it > is useful to have "clone" methods. Why not let "clone $this" produce a > copy that is open to modification within the scope it's cloned in ? or, > why would you limit yourself

[PHP-DEV] Re: Concept: 7.1 nullable function parameter format ...

On 14.09.2016 at 17:10, David (Dj) Eddy wrote: > Issue: Currently the format for nullable function parameters is as > follows: `fn(?int $param)`; this makes little visual sense from an > outside perspective. What does the `?` mean? PHP does not have a `?` > data type; it is very visually

[PHP-DEV] Concept: 7.1 nullable function parameter format ...

Issue: Currently the format for nullable function parameters is as follows: `fn(?int $param)`; this makes little visual sense from an outside perspective. What does the `?` mean? PHP does not have a `?` data type; it is very visually ambiguous. Suggestion: `fn(null|int $param)`. This uses the

[PHP-DEV] Re: Directly embed small strings in zvals

Hello everyone, I was wondering if it would make sense to store small strings (length <= 7) directly inside the zval struct, thereby avoiding the need to extra allocate a zend_string, which would also not entail any costly indirection and refcounting for such strings. The idea would be to add