This is not a snide comment, I'm truly curious. What is the point of "An [x] parser/interpreter/compiler written in [x]." I've seen one now for JS and this one for PHP. I lean more toward the sponge learning [1] side of HN, so forgive me if this is super obvious.
The benefit is that you can use it to transform PHP code into an abstract syntax tree [1]. This allows you to do some really cool things like static analysis, code transformation, preprocessing, etc. in a convenient way.
The fact that it is written in PHP is nice because it allows you to use it in existing PHP projects in an environment you are already familiar with. I think the fact that it is written in PHP is less important than the fact that it can be used in PHP (e.g. it would be equally useful as a PHP extension written in C).
It doesn't necessary apply to this specific posting. But in general, as with many open source projects out there, the point is in increasing author's visibility on the net and assisting author's CV in finding a job.
And there is nothing bad with this. It is just that many authors don't want to articulate on this and are trying to come up with some artificial rationales.
This must be a stupid question because I've noticed that it's commonplace, but why do PHP-based projects try to build templating systems in PHP? Do they not realize that the original use case for PHP was to turn plain HTML files into dynamic templates?
I saw this in Horde, the other day; mixed in with the usual PHP tags they had added their own XML tags for doing "if/else" type things in the template. What is the purpose of that?
I believe it's an attempt to assure there is no logic in the template code.
...which I think is retarded and anal, since the important part is separation of business logic and presentation. There is bound to be some level of display logic, which is why most template languages have loops and conditionals. But if you are going that far, why not just use PHP? It is arguably a very good template language.
Funny you say that, because what you are describing is already implemented and called the Smarty template system[1], one of the worst examples of the Inner-platform effect[2] the world has ever seen.
I'm saying this for years now and people think I hate templates as a concept. I only dislike template systems like Smarty. Ever since I learned that there is a {php}{/php} tag in Smarty, I new the system was broken.
The issue with Smarty is that it is yet another syntax to learn. A PHP template system that uses PHP for the logic and control structures makes a lot more sense IMO.
Well apparently this is not a popular opinion around here but I actually like Smarty when the situation calls for it. In version 3 the "block" feature makes Smarty templates somewhat similar to .NET "Master Pages". I personally like using Smarty as the View in an MVC pattern. I've even used it for email message templates.
I have one reason for not using Smarty in my more recent work but it has nothing to do with my feelings about Smarty itself. Rather just that a lot of web apps lately have all of the view logic in the client. So the server rendering of the view is often just outputting mostly static HTML for the Javascript to use as it's starting point. So it's not that I dislike Smarty, it's just that there's barely any logic at all happening at that level so there's no need for it.
As someone who has been forced to work with on a social web-app using smarty, I find myself asking co-workers to "just kill me now". Hey atleast I'm having a fun time moving all the business logic those smart smarty guys from India put in...right? no more, No but seriously, kill it with fire.
And caching..on disk, who cares? In general, dO we not have better, faster and more versitile options that would in any way justify a choice for smarty?
PHP already has this: the `disable_functions` INI setting.[1]
Disclaimer: I've never had to use this, so don't know what the limitations and pitfalls are for this, and there may be security concerns that I'm unaware of.
Cool... Now define your Node datatype in Haskell deriving Show & Read, and pretty-print to that.
Then you can (easier) do some interesting analysis and transforms!
How does this compare to PHP_CodeSniffer, and it's Tokenizer? You're both using token_get_all under the hood, but PHPCS has support for CSS/JS as well.
PHP_CodeSniffer - as you already say - works with the source code at a token level. This is necessary, because it looks at the precise formatting of the code (like whitespace usage).
The parser is more for analyzers that are not interested in the precise formatting of the code, but want to look at the code from a higher level perspective.
For example, if you want to do control flow analysis and type inference working directly on the tokens would be really hard. An Abstract Syntax Tree makes this kind of work much easier, as you don't have to think about the tiny details of the language.
One of the interesting things about Groovy for me has been the runtime AST transformation stuff - annotating something as @singleton, then having the engine make it in to a singleton at compile time, etc.
Certainly this project doesn't get us there immediately, but might give some neat ideas for future PHP versions to incorporate.
It's only a parser - it just transforms plain source code into an abstract syntax tree representation. However, if you wanted to, you could use this tree for a variety of things - including translating and generating compiled code.
They are very different things. token_get_all just tokenizes the code, but this tool parses PHP code into an AST. If you look at the source of this project, you'll notice that it does indeed use token_get_all to handle the lexing.
[1] http://alexrosen.com/blog/2011/05/sponge-learning/
edit: grammar.