Re: [PHP-DEV] Zend language parser improvements

2014-12-08 Thread Dmitry Stogov
I don't see technical problems with the patch. However, I also don't see any significant benefits. From the user perspective it'll just change error messages and prevent final final class declarations. Nikita, what do you think? Thanks. Dmitry. On Fri, Dec 5, 2014 at 8:18 PM,

Re: [PHP-DEV] Zend language parser improvements

2014-12-08 Thread Damien Tournoud
On Thu, Dec 4, 2014 at 1:46 AM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Examples are COM, PDO Statement, DOM XML and MySQLi. They also reduce the amount of checks of bison when parsing a php file, it provides a nicer fatal error around multiple final and multiple abstract

Re: [PHP-DEV] Zend language parser improvements

2014-12-08 Thread Damien Tournoud
On Mon, Dec 8, 2014 at 1:30 PM, Damien Tournoud d...@damz.org wrote: PDO statement should not be made final, or this is a breaking language change (requiring an RFC and a 2/3 majority). I see from the PR that it's PDORow, not PDOStatement. That one is not actually exposed as such to userspace,

Re: [PHP-DEV] Zend language parser improvements

2014-12-08 Thread guilhermebla...@gmail.com
Hi Dmitry, As I said, these patches are not huge beneficial, but enablers. Enablers in the sense that further development over class/interface/trait simplified. It's not a short win benefit, but a mid/long term. Also defer currently checks done in zend_compile to Bison (such as trait extends and

Re: [PHP-DEV] Zend language parser improvements

2014-12-08 Thread Dmitry Stogov
I'm not against the patch, I'm actually indifferent. Lets wait for Nikita's opinion. I took just a quick look over static class RFC. I'll need to think more about it. Thanks. Dmitry. On Mon, Dec 8, 2014 at 5:18 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi Dmitry, As I

Re: [PHP-DEV] Zend language parser improvements

2014-12-08 Thread Nikita Popov
On Mon, Dec 8, 2014 at 11:45 AM, Dmitry Stogov dmi...@zend.com wrote: I don't see technical problems with the patch. However, I also don't see any significant benefits. From the user perspective it'll just change error messages and prevent final final class declarations. Nikita, what do you

Re: [PHP-DEV] Zend language parser improvements

2014-12-08 Thread guilhermebla...@gmail.com
Nikita, Shouldn't #3 make more sense taking into consideration this commit: https://github.com/guilhermeblanco/php-src/commit/872a97c8dbc1c8823985d9a0305938c508865a0d It is part of a followup PR https://github.com/php/php-src/pull/937 that removes compiler code checks and delegates to bison,

Re: [PHP-DEV] Zend language parser improvements

2014-12-05 Thread guilhermebla...@gmail.com
Hi guys, I'd really appreciate some review around the before-mentioned PRs. I have added a new one to the list now: - https://github.com/php/php-src/pull/937 This PR addresses the parsing support for traits to have extends and implements, as they are invalid. There's another one in the oven,

[PHP-DEV] Zend language parser improvements

2014-12-03 Thread guilhermebla...@gmail.com
Hi, I made some improvements that would like to get merged into PHP, but I require someone with Zend karma to review and merge. The patches are all related and included in each other as a progressive effort. As a quick explanation, the removal of ZEND_ACC_FINAL_CLASS addresses some classes that

Re: [PHP-DEV] Zend language parser improvements

2014-12-03 Thread Levi Morrison
The parser changes need to be careful reviewed; I don't have time at the moment to verify it but I think you unintentionally allowed some syntax's that shouldn't be valid because of the addition to `inner_statement`. Maybe I just looked too quickly. In any case, parser changes should always get

Re: [PHP-DEV] Zend language parser improvements

2014-12-03 Thread guilhermebla...@gmail.com
On Wed, Dec 3, 2014 at 8:06 PM, Levi Morrison le...@php.net wrote: The parser changes need to be careful reviewed; I don't have time at the moment to verify it but I think you unintentionally allowed some syntax's that shouldn't be valid because of the addition to `inner_statement`.