If you're not familiar with PXP already, let me give you a quick breakdown of what the project is.
PXP is a superset of the PHP programming language. It is heavily inspired by the goals of the TypeScript project and aims to improve and enhance PHP with transpilation.
As well as the language itself, I'm also developing a brand new language server for PHP and PXP projects that will be completely open-source and free to use. Our hope is that the language server can compete with closed source and premium solutions such as PHPStorm.
Here's a list of some new language features that I want to bring to you with PXP:
- Auto-capture closures (multi-line short closures)
- Runtime-erased generics
- Type aliases
Why does PXP exist?
PHP has seen many incredible improvements since the release of PHP 7.0 back in 2015. We have support for typed properties, return types, enumerations, match expressions and so much more.
But despite all of these excellent developments it seems many new features that we, PHP developers, really want to see introduced into the language will forever be in discussion or never be implemented.
Let's use the "Auto Capture Closure" proposal as an example. This RFC was opened and it went back and forth with the Internals mailing list, discussing implementation, performance worries etc.
RFCs go through a voting process. The people who are eligible to vote have gained enough "karma" and can therefore have a say in what makes it into the language and what doesn't.
Most RFCs required a 2/3 majority in the vote to pass. In this particular example there were 43 votes, meaning 28/29 people needed to vote "Yes" for it to pass and make it into the next language release. The final vote count was 27 (Yes) to 16 (No). Only a vote or two away from making it into the language.
The vote didn't pass so the RFC now lives alongside the other denied RFCs, awaiting rebirth and reincarnation.
It is these exact features that we could benefit from, daily. I'm sure you have added
use clauses to closures countless times. I'm sure you'd like to see generics baked into the language syntax instead of comments. I'm sure you're starting to see my point.
If the language doesn't want to make the effort to implement these features, it's ultimately left to somebody else to find a way forward. That is why PXP exists.
The tl;dr is that orchestrating and managing a project such as PHP with a large team of internal members will never result in the "perfect" outcome. There are too many (conflicting) opinions that you eventually reach a stalemate and disagreement on things, resulting in features being left behind and denied, just like the "Auto Capture Closure" RFC.
Since PXP is my project, I am instead in control of what makes it into the language. I want the best for my project, but my project is nothing without the users. It's therefore in my best interest to listen to the users and ensure that it does everything that it needs to do for them. I become the benevolent dictator of the project and only have to reason with the people who are actually being impacted by my decisions.
Why transpile/(not fork PHP)/etc?
Why does PXP transpile to PHP? Why doesn't PXP spend countless hours developing a brand new modern runtime?
These are all perfectly valid questions, so let's go through them one by one in reverse order.
Why doesn't PXP spend countless hours developing a brand new modern runtime?
Language development is a hard and time-consuming process. The PHP engine has been in development for more than 20 years at this point, trying to replicate all of that effort in a reasonable amount of time is a hard task.
Why does PXP transpile to PHP?
PXP is a superset. It is backwards compatible with PHP and will forever maintain backwards compatibility. Transpilation means PXP produces perfectly valid PHP code and therefore maintains compatibility with existing PHP tools.
If I go down the route of forking php-src or developing a new runtime / interpreter / engine, all of the existing infrastructure and tooling is instantly useless.
Transpilation also means that you can incrementally adopt PXP. If you've already got a Laravel or Symfony project written in PHP, you can change the file extension of a file to
.pxp, start using PXP's features and it will still work with the rest of your regular PHP code.
What does PXP actually do?
Right now, not a whole lot. My main focus right now is getting the tooling and supporting projects in place to make for an easy transition.
The first feature that I'm focusing on is auto capture closures. The transpilation logic is already in place, that's the easy part. The difficulty lies in the tooling.
PHP doesn't support this feature so IDEs and text editors don't know how to support it. That's why I'm also developing
pls - a free language server for PHP and PXP projects. The main goal right now is making it an excellent language server for PHP projects, with support for things like generics, intelligent code navigation, etc. I want
pls to make PHP development a breeze for all developers in all editors (as long as it supports the Language Server Protocol).
Developing this start-to-finish experience is the deciding factor for the success of the project. Many people have tried to develop a superset before and fell short because of things like IDE support, static analysis, etc.
When can we expect a release?
The main blocker is the language server. Language server development itself isn't a difficult task, but making it powerful and useful is.
I'm aiming to tag an early access beta release in August or September. This release will include the
pls language server with a first-party Visual Studio Code extension, the PXP transpiler itself and a PHPStan plugin.
A large proportion of PHP developers use PHPStorm for their development too. Bringing PXP support to the JetBrains platform is a bit more difficult since it's closed source. I would either need to wait for the introduction of LSP support, or hope that it gains enough traction for JetBrains to implement their own PXP support.