Op 03-08-14 om 02:24 schreef Ingwie Phoenix:
Hello internals!
I have almost completed a SAPI, that allows NodeJS scripters to enable PHP from
within their HTTP servers.
Originally, I wanted to write this extension just for my own use, but as I see
the many „dirty“ hacks that people use to
On 3 Aug 2014, at 05:39, Kris Craig kris.cr...@gmail.com wrote:
Agreed. I'd very much like to see another RFC that proposes more options for
creating an operator for this. The vote against %% on this RFC should not be
construed-- in my opinion, at least-- as a consensus against having any
On 03/08/14 12:52, Andrea Faulds wrote:
Agreed. I'd very much like to see another RFC that proposes more options
for creating an operator for this. The vote against %% on this RFC should
not be construed-- in my opinion, at least-- as a consensus against having
any kind of operator for
On 3 Aug 2014, at 13:24, Lester Caine les...@lsces.co.uk wrote:
That the principle of sorting out 64 bit division is accepted is fairly
obvious from the current stated of the vote? Personally I still view
this as part of the general debate on just how 64bit integers are
supported by default
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Sunday, August 03, 2014 2:52 PM
To: Kris Craig
Cc: Chris Wright; Adam Harvey; PHP internals
Subject: Re: [PHP-DEV] [VOTE][RFC] intdiv()
On 3 Aug 2014, at 05:39, Kris Craig kris.cr...@gmail.com wrote:
Agreed. I'd
On 3 Aug 2014, at 13:51, Zeev Suraski z...@zend.com wrote:
Based on the discussion on internals@ I'm not sure why it should not be
construed as consensus against any kind of operator for intdiv. Quite the
contrary, those who opposed it (myself included) opposed it on the grounds
that it's
On 03/08/14 13:49, Andrea Faulds wrote:
That the principle of sorting out 64 bit division is accepted is fairly
obvious from the current stated of the vote? Personally I still view
this as part of the general debate on just how 64bit integers are
supported by default in new builds of PHP,
On 3 Aug 2014, at 15:27, Lester Caine les...@lsces.co.uk wrote:
Your missing the point I was trying to make. That (int)(3 / 2)
essentially goes wrong only on 64bit systems is the bug that needs
fixing.
(int)(3 / 2) works fine, (int)(PHP_INT_MAX / 3) does not.
It’s not a bug, it’s entirely
On 03/08/14 15:31, Andrea Faulds wrote:
Your missing the point I was trying to make. That (int)(3 / 2)
essentially goes wrong only on 64bit systems is the bug that needs
fixing.
(int)(3 / 2) works fine, (int)(PHP_INT_MAX / 3) does not.
It’s not a bug, it’s entirely intentional and
Good evening,
I am proposing two new RFCs. As they are both inter-related and complementary,
with the second having the first as a prerequisite, I’m making just a single
email to cover both:
https://wiki.php.net/rfc/closure_apply
https://wiki.php.net/rfc/function_referencing
Both have
Hi
I had a similar error and check the src in intervel.c timelib_diff the date
is changed to
local or gmt
from
13-03-01
13-04-01
to
13-02-28
13-03-31
rt-d = two-d - one-d;
and makes it 1 month and 3 days
could it be solved by only running timelib_apply_localtime if date zones are
different or
Hello Andrea,
from userland perspective, I would prefer to open the Closure constructor
instead of adding new syntax:
$qux = new FooBar(3);
// $func = FooBar::getStatic;
$func = new Closure(array('FooBar', 'getStatic'));
$func($qux); // 3
Regards
Thomas
Andrea Faulds wrote on 03.08.2014
On 4 Aug 2014, at 01:53, Thomas Bley ma...@thomasbley.de wrote:
from userland perspective, I would prefer to open the Closure constructor
instead of adding new syntax:
$qux = new FooBar(3);
// $func = FooBar::getStatic;
$func = new Closure(array('FooBar', 'getStatic'));
$func($qux); //
Hey Andrea,
I really love function referencing RFC, this is something I miss in PHP
and would I have a voting right I'd would +1 even in this state of it.
But I dislike a bit the fact that we start to use Closure for everything,
I really wish we had a dedicated type for functions (read
14 matches
Mail list logo
