Re: [PHP-DEV] Return Type Hinting for Methods RFC
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 examples:
// This is allowed
private nullable ArrayIterator getIterator()
{
return null;
}
// This throws an E_RECOVERABLE_ERROR
private ArrayIterator getIterator()
{
return null;
}
The token/identifier can certainly change, but I want to provide the most
options for the best solution.
This looks fine to me, looks more php like then the C# examples.
On Dec 23, 2011, at 6:31 PM, André Rømcke wrote:
2011/12/23 John Crenshaw johncrens...@priacta.com
From: Will Fitch [mailto:will.fi...@gmail.com]
I would like to take this opportunity to query on a consensus:
Would you prefer to allow methods with type hinted return values to
return null at will, or add a marker noting that it *may* return null?
Example: Return null at will
public ArrayIterator getIterator()
{
// something happened, will return null
return null;
}
Example: Return only if identified as such
public ArrayIterator? getIterator()
{
return null;
}
I hate the syntax in the second example (using ?).
It looks strange, but easy to get used to. Two examples from C#:
public decimal? Grade { get; set; }
public NullableSystem.DateTime Time { get; set; }
IMO allowing null should be the default unless specifically disallowed.
I disagree for the reasons mentioned by for instance Robert.
Type hints should be strict/explicit or not done at all.
For the record; This was not ment as an argument against scalar, and
similar type hints ( object, callable.. ) .
It was an argument against hinting about something and getting
something completely different (null).
Happy xmas!
[PHP-DEV] REQUEST_TIME change in PHP 5.4
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 ( https://wiki.php.net/rfc/releaseprocess ) It is not a big deal (we are used to it), but it does break a couple of things in for instance eZ Publish Zeta Components which will by the nature of things not be fixed before the next release. Most customers will hopefully make sure the version of the software they are using is tested/certified for php 5.4 before upgrading, but from experience, some will not. Other then that, happy xmas!
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
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é Rømcke a...@ez.no wrote: 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 ( https://wiki.php.net/rfc/releaseprocess ) It is not a big deal (we are used to it), but it does break a couple of things in for instance eZ Publish Zeta Components which will by the nature of things not be fixed before the next release. Most customers will hopefully make sure the version of the software they are using is tested/certified for php 5.4 before upgrading, but from experience, some will not. Other then that, happy xmas! -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
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 to know how it breaks apps out there. On Sat, Dec 24, 2011 at 12:01 PM, Pierre Joye pierre@gmail.com wrote: 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é Rømcke a...@ez.no wrote: 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 ( https://wiki.php.net/rfc/releaseprocess ) It is not a big deal (we are used to it), but it does break a couple of things in for instance eZ Publish Zeta Components which will by the nature of things not be fixed before the next release. Most customers will hopefully make sure the version of the software they are using is tested/certified for php 5.4 before upgrading, but from experience, some will not. Other then that, happy xmas! -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
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 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é Rømcke a...@ez.no wrote: 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 ( https://wiki.php.net/rfc/releaseprocess ) It is not a big deal (we are used to it), but it does break a couple of things in for instance eZ Publish Zeta Components which will by the nature of things not be fixed before the next release. Most customers will hopefully make sure the version of the software they are using is tested/certified for php 5.4 before upgrading, but from experience, some will not. Other then that, happy xmas! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Proposal] Remove the tail ws in codes
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 developing. On Sat, Dec 24, 2011 at 4:21 AM, Laruence larue...@php.net wrote: Hi: I noted there are a lot of tail white spaces in our codes, it is better to remove them all, and we also should watch such ws in furture. a simple way to erase such ws in vim, use :%s /\s\+$//g thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Atenciosamente, Rafael Kassner -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Proposal] Remove the tail ws in codes
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 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 developing. On Sat, Dec 24, 2011 at 4:21 AM, Laruence larue...@php.net wrote: Hi: I noted there are a lot of tail white spaces in our codes, it is better to remove them all, and we also should watch such ws in furture. a simple way to erase such ws in vim, use :%s /\s\+$//g thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Atenciosamente, Rafael Kassner -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Proposal] Remove the tail ws in codes
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 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 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 developing. On Sat, Dec 24, 2011 at 4:21 AM, Laruence larue...@php.net wrote: Hi: I noted there are a lot of tail white spaces in our codes, it is better to remove them all, and we also should watch such ws in furture. a simple way to erase such ws in vim, use :%s /\s\+$//g thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Atenciosamente, Rafael Kassner -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- Atenciosamente, Rafael Kassner -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
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 and works with all previous
versions, I would like to know how it breaks apps out there.
new DateTime(@{$_SERVER['REQUEST_TIME']}); f.e.
regards,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Proposal] Remove the tail ws in codes
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 you change the code on that line only. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Proposal] Remove the tail ws in codes
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 it a royal pain to do merges later. Please just fix them when you change the code on that line only. It's not only bad for merges, also confusing with blame/annotate while identifying the reason for bug. johannes Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Proposal] Remove the tail ws in codes
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 :) Please don't. Changing whitespace en-masse makes it a royal pain to do merges later. Please just fix them when you change the code on that line only. It's not only bad for merges, also confusing with blame/annotate while identifying the reason for bug. hmm, yes, you are right :), actually, I am not saying that I am going to do such behavior, just remind us that we should watch such CS, since there have been lots of tail ws now... :) thanks johannes Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Proposal] Remove the tail ws in codes
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 en-masse makes it a royal pain to do merges later. Please just fix them when you change the code on that line only. There is no deal or pain to fix them in all branches at once. There is no need either to do it all at once, but doing them while working on a file in a separate commit before the actual change is just fine and is a good practice. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Proposal] Remove the tail ws in codes
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 | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Proposal] Remove the tail ws in codes
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 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 | http://www.libgd.org -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
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
makes very little sense in this case.
While a fix is easy, (int) casting and works with all previous
versions, I would like to know how it breaks apps out there.
new DateTime(@{$_SERVER['REQUEST_TIME']}); f.e.
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:
https://github.com/ezsystems/ezpublish/commit/3483c623769aa9ed3be7b6f33e3579cf8a8efd45
In both cases a (int) was added in front of the variable to make sure it
still behaves the same, so not a big deal.
But as also mentioned, changes like this requires patching to
be compatible with 5.4.
So unless this is done to be inline with some standard on such a server
variable, I would suggest placing microtime on a separate server variable
(since it is indeed useful to have it for time accumulators and performance
metrics).
Re: [PHP-DEV] [Proposal] Remove the tail ws in codes
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 code on that line only. There is no deal or pain to fix them in all branches at once. There is no need either to do it all at once, but doing them while working on a file in a separate commit before the actual change is just fine and is a good practice. 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 rolling back changes a nightmare. Logically it makes a lot more sense simply to leave them alone until such time as a file is touched for other reasons ... and at that time then a separate commit of the WS prior to the bug fix IS good practice. Bundling a whole array of WS fixes across unrelated sections of code is not once you move to any DVCS system. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
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
Datetime($_SERVER['REQUEST_TIME']);
int(1324738540)
Fatal error: Uncaught exception 'Exception' with message
'DateTime::__construct(): Failed to parse time string (1324738540) at
position 8 (4): Unexpected character' in Command line code:1
Stack trace:
#0 Command line code(1): DateTime-__construct('1324738540')
#1 {main}
thrown in Command line code on line 1
5.3.9rc4php -n -r var_dump($_SERVER['REQUEST_TIME']);new
Datetime($_SERVER['REQUEST_TIME']);
int(1324738655)
Fatal error: Uncaught exception 'Exception' with message
'DateTime::__construct(): Failed to parse time string (1324738655) at
position 8 (5): Unexpected character' in Command line code:1
Stack trace:
#0 Command line code(1): DateTime-__construct('1324738655')
#1 {main}
thrown in Command line code on line 1
and with 5.4.0RC4:
5.4.0rc4-ntsphp -n -r var_dump($_SERVER['REQUEST_TIME']);new
Datetime($_SERVER['REQUEST_TIME']);
float(1324738763.2993)
Fatal error: Uncaught exception 'Exception' with message
'DateTime::__construct(): Failed to parse time string
(1324738763.2993) at position 8 (6): Unexpected character' in Command
line code:1
Stack trace:
#0 Command line code(1): DateTime-__construct('1324738763.2993')
#1 {main}
thrown in Command line code on line 1
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
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 is a
float but datetime fails just like before.
php536ntsphp -n -r var_dump($_SERVER['REQUEST_TIME']);new
Datetime($_SERVER['REQUEST_TIME']);
int(1324738540)
Fatal error: Uncaught exception 'Exception' with message
'DateTime::__construct(): Failed to parse time string (1324738540) at
position 8 (4): Unexpected character' in Command line code:1
Stack trace:
#0 Command line code(1): DateTime-__construct('1324738540')
#1 {main}
thrown in Command line code on line 1
5.3.9rc4php -n -r var_dump($_SERVER['REQUEST_TIME']);new
Datetime($_SERVER['REQUEST_TIME']);
int(1324738655)
Fatal error: Uncaught exception 'Exception' with message
'DateTime::__construct(): Failed to parse time string (1324738655) at
position 8 (5): Unexpected character' in Command line code:1
Stack trace:
#0 Command line code(1): DateTime-__construct('1324738655')
#1 {main}
thrown in Command line code on line 1
and with 5.4.0RC4:
5.4.0rc4-ntsphp -n -r var_dump($_SERVER['REQUEST_TIME']);new
Datetime($_SERVER['REQUEST_TIME']);
float(1324738763.2993)
Fatal error: Uncaught exception 'Exception' with message
'DateTime::__construct(): Failed to parse time string
(1324738763.2993) at position 8 (6): Unexpected character' in Command
line code:1
Stack trace:
#0 Command line code(1): DateTime-__construct('1324738763.2993')
#1 {main}
thrown in Command line code on line 1
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
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: https://github.com/ezsystems/ezpublish/commit/3483c623769aa9ed3be7b6f33e3579cf8a8efd45 In both cases a (int) was added in front of the variable to make sure it still behaves the same, so not a big deal. But as also mentioned, changes like this requires patching to be compatible with 5.4. So unless this is done to be inline with some standard on such a server variable, I would suggest placing microtime on a separate server variable (since it is indeed useful to have it for time accumulators and performance metrics). Right, and that's why I would be in favour of a BC change, maybe by introducing a REQUEST_TIME_FLOAT instead, so people willing to use the float version can still have it while the existing code needs no change. Adding Ilia (who made that change) and the RMs to the list. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
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 cost. Introducing additional server variables just makes things inconsistent, especially this late in the release cycle. On Sat, Dec 24, 2011 at 10:07 AM, Pierre Joye pierre@gmail.com wrote: 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: https://github.com/ezsystems/ezpublish/commit/3483c623769aa9ed3be7b6f33e3579cf8a8efd45 In both cases a (int) was added in front of the variable to make sure it still behaves the same, so not a big deal. But as also mentioned, changes like this requires patching to be compatible with 5.4. So unless this is done to be inline with some standard on such a server variable, I would suggest placing microtime on a separate server variable (since it is indeed useful to have it for time accumulators and performance metrics). Right, and that's why I would be in favour of a BC change, maybe by introducing a REQUEST_TIME_FLOAT instead, so people willing to use the float version can still have it while the existing code needs no change. Adding Ilia (who made that change) and the RMs to the list. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
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 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 cost. Introducing additional server variables just makes things inconsistent, especially this late in the release cycle. On Sat, Dec 24, 2011 at 10:07 AM, Pierre Joye pierre@gmail.com wrote: 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: https://github.com/ezsystems/ezpublish/commit/3483c623769aa9ed3be7b6f33e3579cf8a8efd45 In both cases a (int) was added in front of the variable to make sure it still behaves the same, so not a big deal. But as also mentioned, changes like this requires patching to be compatible with 5.4. So unless this is done to be inline with some standard on such a server variable, I would suggest placing microtime on a separate server variable (since it is indeed useful to have it for time accumulators and performance metrics). Right, and that's why I would be in favour of a BC change, maybe by introducing a REQUEST_TIME_FLOAT instead, so people willing to use the float version can still have it while the existing code needs no change. Adding Ilia (who made that change) and the RMs to the list. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug 60596 - With Patch
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, and would likely be optimized away by the compiler anyway, but I figured it was worth cleaning up... Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Proposal] Remove the tail ws in codes
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 suspect you can since you can do non-ws diff manually and then apply it). So I'd suggest at least waiting till we get git running. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
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 unconditionally. With the current patch, I have not added any type of indicator to allow null to be returned at all. This will allow us to discuss things one at a time and determine whether we actually want an indicator added. https://wiki.php.net/rfc/returntypehint2 On Dec 23, 2011, at 4:29 PM, Robert Williams wrote: On 12/23/11 13:34, Will Fitch will.fi...@gmail.com wrote: There's still the matter of whether allowing null to be returned, regardless of the situation, or using another token to identify that it could return null. I'd like to know what others think. I see Stas' argument that you'll still have to check, but I'm not so sure that is such a bad thing. I see it as a very bad thing, for two reasons: 1) Unconditionally allowing null to be returned takes away an element of control. You can't get away from error handling, but it's nice to be able to handle errors how you want. Having nulls thrown at you at any time means you have to be ready to handle them at any time, rather than handling them off in a separate area where you have taken the time to properly prepare for them. This makes for a lot more redundant code unrelated to the core functionality of the code, and it kills much of the utility of things like fluent interfaces. 2) With type-hinted parameters, the choice has already been made not to allow null values at any time. Rather, the programmer must explicitly allow them in the parameter declaration. Doing the same with return types would provide an important bit of consistency. Regards, Bob -- Robert E. Williams, Jr. Associate Vice President of Software Development Newtek Businesss Services, Inc. -- The Small Business Authority https://www.newtekreferrals.com/rewjr http://www.thesba.com/ Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Proposal] Remove the tail ws in codes
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 rolling back changes a nightmare. Perform that as the last svn commit? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug 60596 - With Patch
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 could be choosing in the range instead, with the if. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
