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 user-facing change, in
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. Theref
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* h
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
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 was
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
>>(Compatible with current $m
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 [0-v
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
str
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 "clone $this" produce a
>
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 t
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 ambiguous
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 same
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 a
13 matches
Mail list logo
