Abstract:Rasmus Lerdorf, the founder of the PHP language, was born in 1968 and is 51 years old this year. He released PHP 1.0 in 1995 under the name Personal Home Page Tools. His glory dimmed with Yahoo's decline in search.
In 1997, Israeli programmers Zeev Suraski and Andi Gutmans joined the PHP language development of Zend Company and released PHP 3, PHP 4, PHP 5. Note that there is no PHP 6, and now PHP 7. Zeev Suraski, born in 1975, has been working at Zend for 20 years. Maybe I can't find the direction of development in language, architecture and library work.
A few days ago Zeev Suraski announced his resignation from Zend. The industry was quite surprised. PHP 7 optimization developer Bird Brother said that this was something that had been planned for a long time. It turns out that Zeev Suraski resigned and he wanted to do P. So what is P? He answered through "P idea: FAQ", and the author translated the full text.
Original translation:
This is a mailing list for internals@(internals@: PHP internal developers. Here A FAQ clarification of the ideas presented on the development mechanism involving PHP (which, when internal discussions mature, is made public in externals, often used to submit RFCs and release notifications), which attempts to address many of the issues that have been raised repeatedly in subsequent discussions. .
Note: P is a temporary code name and may change in the future.
What exactly is going on?
Trying to condense the lengthy email content into a few points:
1. There are two big camps in the PHP world. The first one generally likes the dynamics of PHP, with a strong BC bias (BC: Backward Compatibility, also called backward compatibility, compatible with past versions, that is, upgraded software must consider the compatibility of old versions. For example, Word in Office 2019 uses the .docx file format by default, but you can also open the .doc format in Office 2017/2013/2010, or even 2003. The relative concept is called FC, which is Forward Compatibility, which is forward compatible, also called upward compatibility. , that is, the upgraded software will consider future compatibility. This is usually a certain interface and convention in the software, which will still be followed in the future to achieve forward compatibility.), with special emphasis on simplicity, and the other prefers to reduce Get rid of the baggage and have a stricter language with higher level and more complex features.
2. There is no "right" or "wrong" here. Both genres are valid and have very committed followings. However, creating a language that caters to both camps is a challenge, which is a consistent source of debate on internals@.
3. The proposal is to create a new PHP dialect (codename P ) that coexists with PHP but is not bound by the historical philosophy behind the language. In other words, this new dialect may be more restrictive in nature, it may be more bold in eliminating backward compatibility and remove elements that are considered "baggage" (such as short tags), and add more complex features, esp. Those that are well suited to strictly typed languages without introducing the same complexities as PHP dialects.
4. This is not a PHP code branch. The code base will be the same and the developers working on it will be the same. Most of the code is the same. Only specific points of difference between the two dialects will be implemented differently. It's somewhat similar to what strict_types did in PHP 7, just on a larger scale.
Are we really going to do this just because some people can’t give up short tags?
This has nothing to do with short tags, "Deprecating short tags RFC (RFC: Request for Comments, the addition of language features, and standardized change management methods. Usually when new features are added, new Features are submitted to RFCs and examples are given. After the change committee evaluates and approves, the language will be integrated into the implementation source code and incorporated into the new version.)" is not the main motivation for this idea. The goal of this proposal is to be more ambitious, it is to provide a clear vision for PHP and hope to finally resolve the tension between the two camps by giving both camps what they want.
Why fork PHP?
This is not a fork. The code base will be exactly the same, it will be developed by the same people. The binaries will be exactly the same, if you install PHP you will also install P and vice versa. The same binary will run PHP, P or combined PHP/P applications.
Although it's not clear how a file is "marked" as a P file, it may be some kind of special mark at the top of the file, such as:
<?p++?> <?php 'Hello, world!'; ?>
Also, we may find that The entire namespace is marked with P's methods, so the framework does not have to explicitly mark each individual file as P.
This means that our development workload has doubled, and internals@’s contributors are already low. How do we deal with it?
Thankfully, it's not meant to be that way (double the workload). The vast majority of code will be shared between PHP mode and P mode - both source code and runtime.
Whether the file being run is a PHP or P file, the data structures, key subsystems, extensions, web server interfaces, OPcache and all other code will be exactly the same code. The only additional development overhead will be the differences between PHP and P.
Indeed, this means that we have to maintain two versions of certain code snippets, and we will have some if() statements here and there, since P may have extra checks compared to PHP. However, if we are to move to a stricter version of PHP, these elements must be introduced anyway. Furthermore, even those in the strict camp don't recommend that we move to a future strict version without providing a migration path - in fact, the effort involved in this approach is similar to almost any other approach.
When we move to the stricter PHP 8/9, why not just develop a permanently maintained PHP 7.4 long-term maintenance release?
There are many problems with this approach. Even if we ignore the fact that this leaves the huge dynamic preference camp hanging -- without any feature or performance updates -- it's impractical from a development effort perspective. This is different from this proposal, which does, in fact, mean a de facto fork.
Do I need to choose between PHP and P?
Yes and no. As mentioned above, when you install one, you have the other, so as far as applications are concerned, you can run both dialects on one server. However, in practice, projects and individuals may often choose and standardize one or the other, similar to the case of strict types.
Can I mix PHP and P in the same application?
Yes. While we need to determine the precise mechanism, the specification of whether the code is PHP or P will be at the file level, not at the request level. A single execution (request) can load many different files, which can be from both dialects. Code in PHP files will behave as PHP semantics - and code from P files will behave as P semantics. This is also similar to strict_types.
While this may sound awkward at first, there may be very practical use cases. For example, PHP applications use P-only frameworks and vice versa. For those familiar with C and C, this is somewhat similar.
Does this mean PHP will no longer evolve? Will all new features come to P?
No, it just means it will develop differently. Strictness and type-related features may only be available in P , and may only be used in P files. Backward compatibility biases will remain in PHP (this does not mean that backward compatibility will never be broken, just that there must be a good ROI case for each such case).
However, features unrelated to this, such as engine performance improvements (such as JIT), development of extensions, or new asynchronous-related features, are available to both PHP and P.
What are the benefits of this method?
This approach has many benefits. First, it provides a good solution for both camps of internals@. Those who prefer the dynamic nature of PHP can keep it, while those who prefer a more strictly typed language can also get it without any PHP restrictions. The alternative is a zero-sum game, where a victory for one camp is a defeat for the other, and vice versa.
In addition to designing a good technical solution that allows us to support our entire audience with minimal effort, it would end a key source of contention on internals@ in recent years.
Finally, while most readers of this document are likely to be technical people, it should be noted that Launch P will be starting over from a new starting point regardless of the past, potentially with huge positioning and branding advantages. Companies, development managers, and individual developers who are not using PHP are more likely to notice the launch of P than the launch of PHP 8.0 or PHP 9.0.
Aren’t we risking dividing the user base?
In a way, we are. But this is not a flaw in the idea, but a manifestation of the reality that already exists.
As mentioned above, there are a lot of people out there who like the dynamic nature of PHP and are wary of trying to make it more and more type-oriented.
Meanwhile, there's another group of people looking at PHP and thinking to themselves: "Why is it getting so slow that I'm finally going to give up on this dynamic nonsense?" ”
There is no right or wrong here. Both views are valid. When we looked at possible solutions to bridge these two conflicting viewpoints, there weren't many available:
1. Stick with dynamic PHP. This will not be accepted by proponents of stricter language.
2. Develop towards strict PHP. Proponents of dynamic languages will not accept this.
3. Fork the code base. No matter how it is done, it is a net loss option for all participants. There's no technical advantage to doing this, and even if we wanted to (which we don't), we wouldn't have enough contributors to do it.
4. Come up with some creative solutions to meet the needs of both audiences. That's what this proposal attempts to do. It ensures permanent interoperability between the two dialects while keeping the project itself unified. Although this will have a certain degree of fragmentation, it is still the minimum possible to meet everyone's main needs.
How does this differ from the idea of Nikita (a speaker on internals@ who proposed adding features to the version. By the way, the American TV series "Nikita" is worth watching.) version?
There are many similarities between the two ideas, but there are also some substantial differences. Please note that this is based on a limited understanding of version methodology, so parts may be lacking, inaccurate or incorrect.
1. In this proposal, there is a clear goal to keep the current dynamically typed PHP as a long-term, fully supported, equal peer dialect. The release approach treats the current behavior as "legacy". This means that it may be discouraged (used) and then deprecated and removed at some point.
2. The launch strategy is completely different. The P proposal aims to focus first on compatibility breaking elements such as strict operations, changes to type conversion logic, array index handling, requiring variable declarations, etc., and aims to provide them in the first issue of P. The purpose of this is to allow new projects/frameworks to start fresh without knowing that they may have to do a major rewrite in a year or two when more compatibility changes are introduced. The versioning proposal doesn't seem to have such a goal, but instead aims to incrementally add/change elements in PHP.
3. Related to the rollout approach, the versioning approach does not allow for only two dialects, but any number of dialects. We may have a PHP2020 dialect, as well as a PHP2022 dialect and a PHP2027 dialect. If we kept them all, this might actually increase our maintenance complexity.
4. The proposal also mentions different backward-compatibility-breaking strategies for PHP vs. P (conservative vs. aggressive), while versioning schemes may not touch on that topic at all.
5. The version proposal does not have exactly the same positioning/marketing aspects as this proposal.
It is important to note that these two ideas are not necessarily mutually exclusive. We can introduce P and improve it using versions, especially if it proves difficult to fit all the important changes into the first issue of P .
What are the challenges?
There were no shortage of challenges before we could run our first P application.
1. We need support. This means that people on both sides of the aisle need to give up on their dreams of making PHP fully dynamic or fully typed, and ignore those who think differently than they do. This seems to be a very significant challenge.
2. To be successful, the first version of P should handle all, or at least most, compatibility-breaking changes from PHP so that developers who switch (potentially quite painfully) don't have to revisit/ Completely refactor their code. Some expressed concern that due to the limited capabilities of our developers, they might be too optimistic and unable to release in one issue. Once we have a better idea of what the list is about, we have to evaluate this. Note that this does not mean that we need to implement every idea we might have for P in the first issue, just that we should prioritize elements that will trigger a lot of end-user code rewrites and try that before our first release deal with them.
3. Of course, the most challenging thing - we need to find a reasonable name for this new dialect.
Related recommendations:
1. Why is php the best language in the world?
2. PHP is no longer ten years old Previous Bird Sample
3. PHP 7.4 is expected to be released in December 2019
4. 2019Why Will we continue to use PHP?
5. Why do programmers hack PHP? PHP Chinese website has something to say!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
