Re: [PHP-DEV] Could we kill call_user_func?
On Fri, 15 Mar 2013, Steve Clay wrote: call_user_func() just seems so ugly now that we have nicer syntax in so many other areas. That doesn't mean we should just be ripping out functionality that works perfectly fine. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Request: baronth
Translate in italian the pages of the PHP Documentation -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP5.5 beta 1 is ready
Hi Internals, PHP 5.5.0 Beta 1 has been released for testing. As you know, this code base is shipped with Zend OPCache. The packages can be found at: http://downloads.php.net/dsp and windows packages at http://windows.php.net/qa Please test the release carefully and report any bugs. Don't forget to activate Zend OPCache and test your code against it. Report any bug you could find. As you may know, we wont accept any new feature to come in 5.5 by now. Beta stage is meant to make the code base stable and pull a stable release from it. Our next beta is planned for April 4th. We'd like to thank all the contributors for this beta. Regards Julien and David
Re: [PHP-DEV] Could we kill call_user_func?
On 3/21/13 7:37 AM, Derick Rethans wrote: On Fri, 15 Mar 2013, Steve Clay wrote: call_user_func() just seems so ugly now that we have nicer syntax in so many other areas. That doesn't mean we should just be ripping out functionality that works perfectly fine. I was not clear in my initial post. I don't want call_user_func removed, just made unnecessary. To reiterate why: 1. call_user_func fails reference args. (It's not a full substitute for a direct call) 2. Most callable values are already directly callable: ✓ func as string ✓ dynamic method as array ✓ static method as array static method as string ✓ Closure ✓ object with __invoke Closure in object property (I understand why this is off the table) expression containing Closure in object property If always store the callable in a var, the situation is much better: ✓ func as string ✓ dynamic method as array ✓ static method as array static method as string ✓ Closure ✓ object with __invoke ✓ Closure in object property How difficult would it be to support making this work? $c = Foo::bar; $c(); Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Phar Bug #60953
Hi all, I'd like to get some closure on this PR: https://github.com/php/php-src/pull/297 which fixes: https://bugs.php.net/bug.php?id=60953 I've discussed it in brief with both cjones and lawerence. I don't have commit karma for the phar extension, so someone will have to merge this for me. In a nutshell, phar_rename_archive(), which is called from Phar::convertToExecutable(), incorrectly assumes anything after the first dot is a file extension. This causes problems where file names have dots in them, and you attempt to run convertToExecutable(). This patch attempts to fix the problem by making educated guesses as to which the extension is (should be). In most cases, the extension should include a .phar, or some known single or compound format for an extension (like tar.gz). You'll notice some existing tests have changed. This is because the incorrect assumption was propagated through existing tests, and that was fixed, all the tests pass. Finally, if there is a file name extension Phar doesn't already understand, it will simply take the part after the first dot, like it did previously (for BC). Anyone want to assist getting this fix into 5.3-5.5? Or are there any lingering questions on the patch? Thanks, Ralph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Enable Zend OPCache by default in php.ini-development during beta phase?
Hi Internals, I added the default Zend OPCache settings to php.ini-development and php.ini-production atm. To have more people testing the opcache I would like to enable the OPCache in php.ini-development during the beta phase and disable it once we start the first RC. I hope we catch more errors with standard applications. As betas should not be used in production I think we won't have much problems with temporarly enable it. In case there are no objections I will commit this before beta 2. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Enable Zend OPCache by default in php.ini-development during beta phase?
On Thu, Mar 21, 2013 at 4:02 PM, David Soria Parra d...@php.net wrote: Hi Internals, I added the default Zend OPCache settings to php.ini-development and php.ini-production atm. To have more people testing the opcache I would like to enable the OPCache in php.ini-development during the beta phase and disable it once we start the first RC. I hope we catch more errors with standard applications. As betas should not be used in production I think we won't have much problems with temporarly enable it. In case there are no objections I will commit this before beta 2. +1 Be carefull to pass the refresh param to 0sec for the script to be parsed every time. In dev env, one expects its script to be reparsed at every refresh or test. Julien.Pauli
Re: [PHP-DEV] Enable Zend OPCache by default in php.ini-development during beta phase?
hi, On Thu, Mar 21, 2013 at 4:02 PM, David Soria Parra d...@php.net wrote: Hi Internals, I added the default Zend OPCache settings to php.ini-development and php.ini-production atm. To have more people testing the opcache I would like to enable the OPCache in php.ini-development during the beta phase and disable it once we start the first RC. I hope we catch more errors with standard applications. As betas should not be used in production I think we won't have much problems with temporarly enable it. In case there are no objections I will commit this before beta 2. Sounds good and best way to get more tests results. However I'd to suggest to disable the comment optimization as well per default, and maybe reduce the default optimization level (see the reflection bug). Whether we enable it or not per default on final should be decided via an extra vote and based on its status. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fix for #64450
Hi Dmitry, I developed a patch for this one https://bugs.php.net/bug.php?id=64450 . It's regarding to the long overflow in mt_rand(). The main idea is to work with the args as double internally and then return php float if it exceeds the LONG_MAX. I strived to let the old behavior to be unchanged, all the older tests pass. Please take a look. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Method check - Can someone create a RFC for it?
On 21 Mar, 2013, at 2:08 AM, Carlos Rodrigues carlos.v...@gmail.com wrote:
Hi,
I'd like to suggest a new functionality for PHP. I don't know the
internals, and i can't create a patch implementing this. I'm writing
here in case someone likes this idea and write a RFC.
We've had a problem recently where one of our developers forgot an if.
So instead of writing
if ($obj-image) {
echo $obj-image-getUrl();
}
He wrote:
echo $obj-image-getUrl();
Here, locally, it was working cause we had the image. But when we
updated the online version we got a Fatal error: Call to a member
function getUrl() on a non-object cause someone didn't upload the
image in one of the records that we're on the home page.
Fatal errors like this can't be catched by a try/catch. And since this
getUrl() was not essential for the page, we'd better output an empty
string then having the site offline.
You can register a shutdown function with register_shutdown_function() and
check for error_get_last() inside.
In most cases you can't really handle this particular error very well anyway.
At least with this you can have the full error emailed to you if you wish and
print some kind of error message on the page.
One might say: you guys should have tested it better, or The image
field should be mandatory in the back end.
And it's true, he should have written that extra if {}.
Examining this problem we happened to stumble open Ruby's and
Coffescript's method check.
Something like this:
$obj-image?-getUrl()?;
So my suggestion is:
Create something like $foo-bar?() or $foo-bar()?, where you don't
care whether the function exists, or if $foo is an object. If it
doesn't exist you just return null.
I guess there are plenty of systems out there where it's better to
output an empty string than having your site offline, just cause the
programmer couldn't test it completely.
Thanks for reading it.
Carlos Rodrigues
--
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
[PHP-DEV] PHP 5.5 Upgrade Notes Question
Hi, Just reading the excellent PHP 5.5 Upgrades Notes - https://raw.github.com/php/php-src/php-5.5.0beta1/UPGRADING Some questions: - Dropped support for Windows XP 2003: o Was this an RFC? At what point was it decided? (I may have missed it in that case I’d just appreciate a pointer to where it was decided). I am asking because XP still seems to be quite prevalent and while Microsoft wants to incentivize people to upgrade by being aggressive around end of life, not sure that’s the most convenient for our users. - In “Backwards Incompatible Changes” there’s a big list of BC changes that are internals and don’t impact user land. So could come across a lot more intimidating than it is. I think we should move towards the end of the upgrade notes in a section of its own that’s “PHP Internals Changes – does not impact user space” (or something of that sort). I’m happy to make that change but wanted to bring it up before tackling it. - On similar note as previous item, should we put New Features before BC changes? No big deal but it’s always nice to have the more positive piece first :) Andi
