On Sat, Dec 24, 2011 at 8:40 AM, Will Fitch will.fi...@gmail.com wrote:
In the interest of providing options for an ability to mark a method as
returning null, I have added a new patch here:
http://www.willfitch.com/php/nullable.patch
This includes a new token T_NULLABLE. Here are a few
Hi,
a bit late to the party maybe, but why was REQUEST_TIME broken in 5.4
instead of adding a new parameter? (like REQUEST_MICROTIME)
Is the Release Process not followed yet?
- x.y.z to x.y+1.z
- (...)
- Backward compatibility must be kept
(
hi,
I don't remember a change about it and did not check the log yet.
Would you mind to write here how it is broken please? It could help
the discussions :)
But yes, if it has changed in an incompatible way, I'd to go with a
revert as well.
Cheers,
On Sat, Dec 24, 2011 at 11:13 AM, André
hm, I should read better...
The REQUEST_TIME value inside server now returns a floating point number
How does it break BC except if one is doing a strong type test? which
makes very little sense in this case.
While a fix is easy, (int) casting and works with all previous
versions, I would like
Haven't tried myself yet but could it be André is refering to a change
from Ilia from 11/2010?
http://git.php.net/?p=php-src.git;a=commit;h=435783f703bc762aad0f9269234bd383d4a55230
Kind regards,
Stefan
On 12/24/2011 12:01 PM, Pierre Joye wrote:
hi,
I don't remember a change about it and
AFAIK, PHP files are transformed in bytecode before the execution, so
white spaces will not interfere in nothing except more time to
transfer the file over SFTP.
It's pretty good to implement on our IDEs (and a lot of them is doing
it), once trailing white spaces are annoying while we are
hi!
Laruence refers to the PHP C source code and removing trailing white
spaces is a good thing as it is part of our CS.
Go ahead Laruence :)
On Sat, Dec 24, 2011 at 12:09 PM, Rafael Kassner kass...@gmail.com wrote:
AFAIK, PHP files are transformed in bytecode before the execution, so
white
Oh, shame on my, I was thinking about PHP code. Even so, this is
coding standards for PHP C code. Have we this? This can be a good one.
On Sat, Dec 24, 2011 at 9:11 AM, Pierre Joye pierre@gmail.com wrote:
hi!
Laruence refers to the PHP C source code and removing trailing white
spaces is a
On Sat, 24 Dec 2011, Pierre Joye wrote:
hm, I should read better...
The REQUEST_TIME value inside server now returns a floating point number
How does it break BC except if one is doing a strong type test? which
makes very little sense in this case.
While a fix is easy, (int) casting
On Sat, 24 Dec 2011, Pierre Joye wrote:
Laruence refers to the PHP C source code and removing trailing white
spaces is a good thing as it is part of our CS.
Go ahead Laruence :)
Please don't. Changing whitespace en-masse makes it a royal pain to do
merges later. Please just fix them when
On Sat, 2011-12-24 at 11:56 +, Derick Rethans wrote:
On Sat, 24 Dec 2011, Pierre Joye wrote:
Laruence refers to the PHP C source code and removing trailing white
spaces is a good thing as it is part of our CS.
Go ahead Laruence :)
Please don't. Changing whitespace en-masse makes
2011/12/24 Johannes Schlüter johan...@schlueters.de:
On Sat, 2011-12-24 at 11:56 +, Derick Rethans wrote:
On Sat, 24 Dec 2011, Pierre Joye wrote:
Laruence refers to the PHP C source code and removing trailing white
spaces is a good thing as it is part of our CS.
Go ahead Laruence :)
On Sat, Dec 24, 2011 at 12:56 PM, Derick Rethans der...@php.net wrote:
On Sat, 24 Dec 2011, Pierre Joye wrote:
Laruence refers to the PHP C source code and removing trailing white
spaces is a good thing as it is part of our CS.
Go ahead Laruence :)
Please don't. Changing whitespace
2011/12/24 Johannes Schlüter johan...@schlueters.de:
It's not only bad for merges, also confusing with blame/annotate while
identifying the reason for bug.
Huh, since when do we commit or recommend to commit WS changes with
actual changes?
--
Pierre
@pierrejoye | http://blog.thepimp.net |
Hi:
It is necessary that highlight the tail ws in view svn. that can help
us avoid adding more tail ws ..
:)
thanks
2011/12/24 Pierre Joye pierre@gmail.com:
2011/12/24 Johannes Schlüter johan...@schlueters.de:
It's not only bad for merges, also confusing with blame/annotate while
On Sat, Dec 24, 2011 at 12:55 PM, Derick Rethans der...@php.net wrote:
On Sat, 24 Dec 2011, Pierre Joye wrote:
hm, I should read better...
The REQUEST_TIME value inside server now returns a floating point
number
How does it break BC except if one is doing a strong type test? which
Pierre Joye wrote:
Laruence refers to the PHP C source code and removing trailing white
spaces is a good thing as it is part of our CS.
Go ahead Laruence:)
Please don't. Changing whitespace en-masse makes it a royal pain to do
merges later. Please just fix them when you change the
On Sat, Dec 24, 2011 at 12:55 PM, Derick Rethans der...@php.net wrote:
new DateTime(@{$_SERVER['REQUEST_TIME']}); f.e.
Not following you here, how does it work better in 5.3.x? It is a
float but datetime fails just like before.
php536ntsphp -n -r var_dump($_SERVER['REQUEST_TIME']);new
You missed the @ before the number ;)
On Sat, Dec 24, 2011 at 4:00 PM, Pierre Joye pierre@gmail.com wrote:
On Sat, Dec 24, 2011 at 12:55 PM, Derick Rethans der...@php.net wrote:
new DateTime(@{$_SERVER['REQUEST_TIME']}); f.e.
Not following you here, how does it work better in 5.3.x? It
On Sat, Dec 24, 2011 at 3:47 PM, André Rømcke a...@ez.no wrote:
Yes, this is the one from Zeta Components MvcTools.
In eZ Publish it was db based session gc using REQUEST_TIME
and compatibility for potential extensions that might have used this
variable via eZ Publish
api:
In most instances integers and floats can be used interchangeably,
which is why the patch was written in the way that it was. In the few
rare cases (int) cast takes care of the trick, there is a substantial
benefit for timings etc... to have higher precision timestamp
available at no additional
hi Ilia,
Right but there is a clear BC break here. And yes I really don't like
how datetime deals with that but it is how it is, and it is certainly
the only case where it fails (or almost).
On Sat, Dec 24, 2011 at 4:18 PM, Ilia Alshanetsky i...@ilia.ws wrote:
In most instances integers and
Hey all,
I found a superfluous if statement while investigating another issue.
I submitted a bug to clean it up and attached a patch:
https://bugs.php.net/bug.php?id=60596
It's on line 56 of /ext/spl/spl_engine.c :
http://lxr.php.net/xref/PHP_TRUNK/ext/spl/spl_engine.c#56
It's really simple,
Hi!
It's not only bad for merges, also confusing with blame/annotate while
identifying the reason for bug.
As soon as we move to git, IIRC git has ability to separate ws-changes
from non-ws ones and do diffs/history while ignoring ws. I didn't figure
out if you can do non-ws merge (I
The RFC and patch has been updated to include the nullable functionality that
addresses the concerns mentioned by Stas.
https://wiki.php.net/rfc/returntypehint2
On Dec 23, 2011, at 5:02 PM, Will Fitch wrote:
I have updated the RFC and patch to reflect not allowing null to be returned
On 24/12/11 15:55, Lester Caine wrote:
I'm with Derek ... having commits that are just WS corrections can be
irritating when tracking changes ... but it would most definitely
better to get them fixed before moving to git which would lump mass
commits like that together in a change set and make
On 24/12/11 18:22, Anthony Ferrara wrote:
It's really simple, and would likely be optimized away by the compiler
anyway, but I figured it was worth cleaning up...
Yep, it's straightforward.
I'm not sure if it makes a difference or not.
IS_DOUBLE is between IS_LONG and IS_BOOL so the compiler
27 matches
Mail list logo
