[PHP-DEV] Requesting RFC karma

2015-09-03 Thread Nikita Nefedov
Hey everyone, I'm asking for some RFC karma for wiki account nikita2206 in preparation of callable typehints RFC [0] with Marcio, and some other RFCs in the future. Thanks in advance \O/ [0] https://wiki.php.net/rfc/callable-types -- PHP Internals - PHP Runtime Development Mailing List To

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

2015-09-03 Thread Tom Worster
On 9/2/15 5:34 PM, Rowan Collins wrote:> On 02/09/2015 20:44, Tom Worster wrote: >> In other words, ~> will end my career. Thanks :P > > I know this line is just hyperbole, but it does rather sum up the tone > of the rest of your e-mail. I'm honestly not sure how you expect anyone > to respond.

Re: [PHP-DEV] Requesting RFC karma

2015-09-03 Thread Marcio Almada
+1 He did most of the hard work for this particular RFC already, so it would be great to give him permission to edit too. 2015-09-03 11:08 GMT-03:00 Nikita Nefedov : > Hey everyone, > > I'm asking for some RFC karma for wiki account nikita2206 > in preparation of callable

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

2015-09-03 Thread Rowan Collins
Tom Worster wrote on 03/09/2015 15:46: The unspoken rules of civility make some people suppress negative reactions to the proposal. In this case it was even implied, as you point out, that dissenting opinion is unwelcome. But I don't think such constraints are entirely fair so I gave my opinion.

Re: [PHP-DEV] Re: Add HTTP/2 Multiplexing-related constants to ext/curl

2015-09-03 Thread Jan Ehrhardt
Pierre Joye in php.internals (Thu, 3 Sep 2015 18:40:06 +0700): >On Sep 3, 2015 2:48 PM, "Jan Ehrhardt" wrote: >> >> Davey Shafik in php.internals (Wed, 2 Sep 2015 17:31:44 +1200): >> >I'd love to see this make it into PHP 7.0 if it's not too late? It's >> >extremely trivial,

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

2015-09-03 Thread Pavel Kouřil
On Thu, Sep 3, 2015 at 12:48 AM, Rowan Collins wrote: > > So I would like to put forward for consideration these amendments to the > proposal, in the spirit of compromise (in no particular order; numbers are > just for reference in future discussion): > > Amendment 1.

Re: [PHP-DEV] PDO: Disable emulated prepares by default?

2015-09-03 Thread Kalle Sommer Nielsen
Hi Scott 2015-09-03 6:14 GMT+02:00 Scott Arciszewski : > > Inspired by http://stackoverflow.com/a/12202218/2224584 > > Can we (in either PHP 7.0 or in PHP 7.1) turn emulated prepared > statements off by default, and still allow developers to turn it on if > they really want

Re: [PHP-DEV] Heads up: merging security patches to 7

2015-09-03 Thread Yasuo Ohgaki
Hi Stas, On Thu, Sep 3, 2015 at 1:56 PM, Stanislav Malyshev wrote: >> I see number of var_push_dtor() to fix unserialization. >> var_push_dtor() or var_push_dtor_no_addref() is required always when >> php_var_unserialize() is failed. >> Am I correct? > > Not necessarily.

Re: [PHP-DEV] PDO: Disable emulated prepares by default?

2015-09-03 Thread Scott Arciszewski
On Thu, Sep 3, 2015 at 4:08 AM, Kalle Sommer Nielsen wrote: > Hi Scott > > 2015-09-03 6:14 GMT+02:00 Scott Arciszewski : >> >> Inspired by http://stackoverflow.com/a/12202218/2224584 >> >> Can we (in either PHP 7.0 or in PHP 7.1) turn emulated prepared >>

Re: [PHP-DEV] PDO: Disable emulated prepares by default?

2015-09-03 Thread Scott Arciszewski
On Thu, Sep 3, 2015 at 2:33 AM, Ferenc Kovacs wrote: > > 2015. szept. 3. 6:14 ezt írta ("Scott Arciszewski" ): >> >> Inspired by http://stackoverflow.com/a/12202218/2224584 >> >> Can we (in either PHP 7.0 or in PHP 7.1) turn emulated prepared >> statements

Re: [PHP-DEV] PDO: Disable emulated prepares by default?

2015-09-03 Thread Ferenc Kovacs
2015. szept. 3. 6:14 ezt írta ("Scott Arciszewski" ): > > Inspired by http://stackoverflow.com/a/12202218/2224584 > > Can we (in either PHP 7.0 or in PHP 7.1) turn emulated prepared > statements off by default, and still allow developers to turn it on if > they really want

[PHP-DEV] Re: Add HTTP/2 Multiplexing-related constants to ext/curl

2015-09-03 Thread Jan Ehrhardt
Davey Shafik in php.internals (Wed, 2 Sep 2015 17:31:44 +1200): >I'd love to see this make it into PHP 7.0 if it's not too late? It's >extremely trivial, but whatever — not that fussed :) > >PR is here: https://github.com/php/php-src/pull/1497 I applied the same patch to the sources of the almost

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

2015-09-03 Thread Björn Larsson
Den 2015-09-03 kl. 11:56, skrev Rowan Collins: Pavel Kouřil wrote on 03/09/2015 07:32: Amendment 2. Make the ~> operator non-associative Why? Once you read documentation about how the operator works and what it does, you will know it and writing the extra brackets seems superfluos. And

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

2015-09-03 Thread Rowan Collins
Pavel Kouřil wrote on 03/09/2015 07:32: I wouldn't mind the mandatory ( ) around parameters, but at the same time I think that it's an useless rule and makes the written code more "cluttered" (too much ( and ) imho make the code less readable). Bear in mind that under the current proposal, the

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

2015-09-03 Thread Rowan Collins
Pavel Kouřil wrote on 03/09/2015 07:32: Amendment 2. Make the ~> operator non-associative Why? Once you read documentation about how the operator works and what it does, you will know it and writing the extra brackets seems superfluos. And woudn't this complicate the parser even more? Also,

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

2015-09-03 Thread Rowan Collins
Dan Cryer wrote on 03/09/2015 11:40: Out of interest, is there a technical reason you couldn't use an existing token, such as => for this? https://wiki.php.net/rfc/short_closures#symbol_choice In particular, note that this is already valid code: [$x => $x * 2] (A one-element array, specifying

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

2015-09-03 Thread Dan Cryer
> > I had this RFC in draft since some time, but delayed it due to all the > ongoing PHP 7 discussions. Also we have no master branch to merge features > in until 5.4 EOL. Thus I'm reviving this now. > > Time for the first RFC targeting PHP 7.1 (assuming PHP 8 isn't going to be > the next version

[PHP-DEV] Benchmark Results for PHP Master 2015-09-03

2015-09-03 Thread lp_benchmark_robot
Results for project php-src-nightly, build date 2015-09-03 11:56:02+03:00 commit: 49ee37d870a5eb607ad9a6d4be9b5fe547ff0949 revision_date: 2015-09-02 23:15:57-07: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] PDO: Disable emulated prepares by default?

2015-09-03 Thread Ferenc Kovacs
On Thu, Sep 3, 2015 at 8:33 AM, Ferenc Kovacs wrote: > > 2015. szept. 3. 6:14 ezt írta ("Scott Arciszewski" ): > > > > Inspired by http://stackoverflow.com/a/12202218/2224584 > > > > Can we (in either PHP 7.0 or in PHP 7.1) turn emulated prepared > >

Re: [PHP-DEV] Re: Add HTTP/2 Multiplexing-related constants to ext/curl

2015-09-03 Thread Pierre Joye
On Sep 3, 2015 2:48 PM, "Jan Ehrhardt" wrote: > > Davey Shafik in php.internals (Wed, 2 Sep 2015 17:31:44 +1200): > >I'd love to see this make it into PHP 7.0 if it's not too late? It's > >extremely trivial, but whatever — not that fussed :) > > > >PR is here:

Re: [PHP-DEV] PDO: Disable emulated prepares by default?

2015-09-03 Thread Lester Caine
On 03/09/15 12:25, Ferenc Kovacs wrote: >> Last time we discussed this it was Anthony who proposed the change and >> > Rasmus shed some light on why did we have the emulation in the first place. >> > We can have change the default but we should have an RFC clearly stating >> > the impact (an

[PHP-DEV] [RFC] [DISCUSSION] More precise float value

2015-09-03 Thread Yasuo Ohgaki
Hi all, IEEE 754 double cannot express exact float values. That said, float values expressed by json/serialize/var_export/echo/print are not precise enough in many cases. Issues: - json_encode() uses EG(precision)=14 that truncates float values. echo()/print() does this as well. - large

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

2015-09-03 Thread Sara Golemon
On Wed, Sep 2, 2015 at 3:48 PM, Rowan Collins wrote: > Amendment 1. Only allow the single-expression form of the short syntax; full > function bodies must be declared with the existing function(){ ... } syntax. > This gives a clearer distinction between how the two