Hi! > Nikita is doing an amazing job with PHP_Parser, which is such a > third-party tool. However, it will always lag behind the canonical > parser. And it will (probably) never match 100% the behavior of the > canonical parser.
Wait, so the arguments that it will be amazingly easy to implement new features in this parser - which should solve the problem of the lag - by the time the old and clunky parser is released certainly it is possible to do the same with new, much less complex and much easier to work with parser? - so these arguments weren't true? Or am I missing some important reason why parser that is much less complex and easier to add things to can't do the same old one can do? And if it's impossible to match behavior of the existing parser - do I get it right that the proposed idea is to actually break real code that people run now in PHP because it was too hard to parse for people that write add-on tools to PHP? Somehow it does not sound like a good idea. If we have doubt that we can match the existing PHP behavior then the idea of changing parser becomes even less appealing, because for 99% of PHP users it would be pure downside without upsides. The users don't care if the parser is complex, they care if their code runs. > This is why, from my perspective of someone who is interested in static > analysis and quality assurance, I think that it would be a tremendous > boost for the PHP platform if we had a state-of-the-art parser for the > reference implementation of our programming language. I think that the benefit of it for regular PHP user is unclear (and would not be clear until the real benefit of such parser - such as promised optimizations, etc. - is demonstrated) but the harm from breaking of the existing code is obvious. What would happen is that people would just avoid running such PHP version - and what use then would be to have excellent tools for PHP that people don't use because it can't run their code? -- 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
