On 03/04/2016 03:49 PM, Johannes Schlüter wrote:
On Fri, 2016-03-04 at 12:29 -0600, Stephen Coakley wrote:
Not a complete polyfill, since $newfunc is a closure and not a string,
so you cannot print out the function name. I have no idea if any code
relies on the lambda itself being a string thoug
On Fri, 2016-03-04 at 12:29 -0600, Stephen Coakley wrote:
> Not a complete polyfill, since $newfunc is a closure and not a string,
> so you cannot print out the function name. I have no idea if any code
> relies on the lambda itself being a string though.
This has impact on a few things, i.e. Re
On 02/18/2016 04:45 PM, Zeev Suraski wrote:
With rand functions, I don't think we need to touch them. For some
applications, low-key randomness is just fine - if you need to shuffle
array of 20 elements or randomize unit test to ensure you're not testing
same value all the time, low-quality ran
On 03/04/2016 07:53 AM, Johannes Schlüter wrote:
On Thu, 2016-02-18 at 19:57 +, Andrea Faulds wrote:
I've actually used create_function on occasion for programmatically
generating functions (in particular to create a function for each PHP
operator), but it's trivially polyfillable, and it'd
On 02/18/2016 06:41 AM, Nikita Popov wrote:
Hi internals!
I've created a bulk-deprecation RFC for PHP 7.1:
https://wiki.php.net/rfc/deprecations_php_7_1
I'm using this RFC to collect various deprecations targeting PHP 7.1, as
having individual RFCs for these is too much management overhead. Eac
Results for project PHP master, build date 2016-03-04 16:55:59+02:00
commit: df87963
previous commit:de3e033
revision date: 2016-03-04 12:27:43+01:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
On Thu, 2016-02-18 at 19:57 +, Andrea Faulds wrote:
> I've actually used create_function on occasion for programmatically
> generating functions (in particular to create a function for each PHP
> operator), but it's trivially polyfillable, and it'd be better if
> people
> were implementing i
On 04/03/16 11:36, Rowan Collins wrote:
> Lester Caine wrote on 04/03/2016 11:19:
>> My main reason for not taking that brute force approach is actually the
>> same. Many of the comment 'var' entries relate to the use of the
>> identified var. So changing one without the other just creates more
>>
Lester Caine wrote on 04/03/2016 11:19:
My main reason for not taking that brute force approach is actually the
same. Many of the comment 'var' entries relate to the use of the
identified var. So changing one without the other just creates more
problems? It's the documentation style from 15 years
On 03/03/16 13:24, Rowan Collins wrote:
>> Actually my problem is even more simple than that - although it may be
>> possible to further filter the lookup for 'var ' ( note the space ) many
>> of the results are simply not text that needs changing.
>
> The script that Colin linked
> (https://gist.
Davey Shafik wrote on 04/03/2016 07:17:
1. If you simply alias (use foo { bar as bat; }) then you end up with an
*additional* method with the new name, the trait method as defined is still
brought in, and_will_ override inherited methods of the same name.
Here's a clearer example of this: htt
wrote in message news:56d86c00.6000...@fleshgrinder.com...
On 3/3/2016 10:34 AM, Tony Marston wrote:
If you want to avoid such confusion over alias names then surely that
would be an argument against introducing aliases in the first place. In
this case the short array syntax would never have be
12 matches
Mail list logo
