Re: [PHP-DEV] [VOTE] Error message formatting for development
On Wed, 3 Aug 2011, Derick Rethans wrote: The RFC and patch can be found here: https://wiki.php.net/rfc/error-formatting-for-developers You can vote here: https://wiki.php.net/rfc/error-formatting-for-developers#vote Voting is now closed and the RFC was accepted 16 for and 0 against. The patch has been committed. cheers, 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
[PHP-DEV] Property get/set syntax
Hi, From time to time I'm looking over the existing RFCs and I'm wondering what happens to them. For example Property get/set syntax [1]. As far as I can see its already accepted for PHP6 [2], but now it seems to be orphaned. In my opinion it is a very nice enhancement, that helps to get rid of the Getter/Setter-mess. Are there any plans? Bye, Sebastian [1] https://wiki.php.net/rfc/propertygetsetsyntax [2] https://wiki.php.net/todo/php60 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Property get/set syntax
On Wed, Aug 10, 2011 at 8:05 PM, Sebastian Krebs sebastian.krebs.ber...@googlemail.com wrote: Hi, From time to time I'm looking over the existing RFCs and I'm wondering what happens to them. For example Property get/set syntax [1]. As far as I can see its already accepted for PHP6 [2], but now it seems to be orphaned. In my opinion it is a very nice enhancement, that helps to get rid of the Getter/Setter-mess. Are there any plans? @internals - Is this something that could be proposed for 5.4.0? or is it too late. Bye, Sebastian [1] https://wiki.php.net/rfc/**propertygetsetsyntaxhttps://wiki.php.net/rfc/propertygetsetsyntax [2] https://wiki.php.net/todo/**php60 https://wiki.php.net/todo/php60 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Static method call syntax on objects
Is this exepcted behaviour? ➜ ~ cat test.php ?php class Foo { public static function bar() { print __METHOD__ . \n; } } $foo = new Foo; $foo::bar(); ➜ ~ php test.php Foo::bar I, for one, was surprised that this does what it does with PHP 5.3 and PHP 5.4 (do not have older version of PHP hand). -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Property get/set syntax
Hi Sebastian 2011/8/10 Sebastian Krebs sebastian.krebs.ber...@googlemail.com: Hi, From time to time I'm looking over the existing RFCs and I'm wondering what happens to them. For example Property get/set syntax [1]. As far as I can see its already accepted for PHP6 [2], but now it seems to be orphaned. In my opinion it is a very nice enhancement, that helps to get rid of the Getter/Setter-mess. Are there any plans? This RFC by Dennis was never 100% finalized, however from what I remember it was suggested too late in 5.3's development process to be implemented, and so do I think we are in 5.4 already as the RFC would need some extra care before sent to the list, perhaps even a patch for parts of it. The RFC itself evolved quite a bit doing its drafts on the wiki, I remember having long emails with Dennis about the syntax, as it evolved to allow many more things and additions to the object model, like final properties, interfaces with properties, getters, setters, But in the end I think it would rime greatly with traits and other goodies in 5.4 if someone took the time and care for this RFC, just worried its way too late already. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Static method call syntax on objects
Hi! On 8/10/11 1:12 PM, Sebastian Bergmann wrote: Is this exepcted behaviour? ➜ ~ cat test.php ?php class Foo { public static function bar() { print __METHOD__ . \n; } } $foo = new Foo; $foo::bar(); ➜ ~ php test.php Foo::bar I, for one, was surprised that this does what it does with PHP 5.3 and PHP 5.4 (do not have older version of PHP hand). This is how FETCH_CLASS works now - when it has an object in where it expects class name, it uses object's class. We could call toString() instead but that might be even more surprising. -- 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] Static method call syntax on objects
Hello, On Wed, Aug 10, 2011 at 22:20, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 8/10/11 1:12 PM, Sebastian Bergmann wrote: Is this exepcted behaviour? ➜ ~ cat test.php ?php class Foo { public static function bar() { print __METHOD__ . \n; } } $foo = new Foo; $foo::bar(); ➜ ~ php test.php Foo::bar I, for one, was surprised that this does what it does with PHP 5.3 and PHP 5.4 (do not have older version of PHP hand). This is how FETCH_CLASS works now - when it has an object in where it expects class name, it uses object's class. We could call toString() instead but that might be even more surprising. Well, FETCH_CLASS has always worked like that, but previously (5.3) variables for class references were only allowed as part of the new statement, e.g. new $obj; The semantic remains the same, only that now variables are also allowed for :: calls (since 5.3). -- 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 -- Etienne Kneuss http://www.colder.ch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Line markers in PHP
I've just created a new RFC, https://wiki.php.net/rfc/linecontrol , regarding adding cpp(1)'s linemarkers to PHP. Discussion is invited. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Property get/set syntax
On Wed, Aug 10, 2011 at 10:16 PM, Kalle Sommer Nielsen ka...@php.netwrote: Hi Sebastian 2011/8/10 Sebastian Krebs sebastian.krebs.ber...@googlemail.com: Hi, From time to time I'm looking over the existing RFCs and I'm wondering what happens to them. For example Property get/set syntax [1]. As far as I can see its already accepted for PHP6 [2], but now it seems to be orphaned. In my opinion it is a very nice enhancement, that helps to get rid of the Getter/Setter-mess. Are there any plans? This RFC by Dennis was never 100% finalized, however from what I remember it was suggested too late in 5.3's development process to be implemented, and so do I think we are in 5.4 already as the RFC would need some extra care before sent to the list, perhaps even a patch for parts of it. Type hinting is for instance not covered (should imho at least be on pair with function signatures). The RFC itself evolved quite a bit doing its drafts on the wiki, I remember having long emails with Dennis about the syntax, as it evolved to allow many more things and additions to the object model, like final properties, interfaces with properties, getters, setters, But in the end I think it would rime greatly with traits and other goodies in 5.4 if someone took the time and care for this RFC, just worried its way too late already. On 6.0 todo list: There are lots of things that would be nice additions to php on the 6.0 todo list*. If all these have been voted for in the past, I'll suggest that they could be worked on in upcoming 5.x versions as well leading up to an eventual 6.0 version. *eg: - Property overloading RFC aka abstract/virtual properties and get/set handlers (derick) (related?) - add support for type-hinted return values. *caugh* - add ability to allocate persistent zvals in PHP. - add support for files 2GB once native 64bit integers are implemented (pierre,wez) - APC - include APC in the core distributions (turned off by default) and switch to mmap as default shared memory storage. - ability to move autoloaded main classes in apc's class lookup preventing the overhead of doing the inheritance process all the time. (marcus) -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Line markers in PHP
In my eyes this change isn't necessary and if it is, not with this syntax. First the syntax: PHP is not C, we do not have preprocessing instructions using hash notation. Such a syntax seems unfamiliar in PHP. Additionally # is already used for single line comments so there's actually is no backwards compatability: Old code that accidentally was of your proposed form would trigger a line marker, potentially causing much confusion when debugging. If we really do need such a feature it should follow PHP's declare syntax: declare(line=17, file='hi'); // or declare(line=5) { // ... } Now concerning your use cases: It is fairly easy to rewrite PHP errors. One of the examples you give are Smarty templates. Twig (another template engine), already does line number rewrites by inserting `// line ...` comments into the template and extracting that information using the tokenizer. (https://github.com/fabpot/Twig/blob/master/lib/Twig/Error.php#L147) It's not terribly complicated. And this is the most complex case, where line number distribution is not just off-by-n, but really requires line-hints in the source. For the PHPT tests a simple addition of the number of lines before the actual test will suffice. Even no tokenizer needed. (Sorry, forgot to send to list) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php