faq

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2019/08/09 18:53		current
Line 1:		Line 1:
-	===== P++ idea: FAQ =====	+	====== P++ idea: FAQ ======
		+	* Date: 2019-08-09
		+	* Author: Zeev Suraski, zeev@php.net
		+

	This is a clarifying FAQ for the idea presented on [[https://marc.info/?l=php-internals&m=156529545007909&w=2\|internals@]]. It attempts to address many points that were raised repeatedly in the discussion that ensued.		This is a clarifying FAQ for the idea presented on [[https://marc.info/?l=php-internals&m=156529545007909&w=2\|internals@]]. It attempts to address many points that were raised repeatedly in the discussion that ensued.
Line 7:		Line 11:

	Trying to shorten the lengthy email into a couple of points:		Trying to shorten the lengthy email into a couple of points:
-	- There are two big, substantial schools of thought in the PHP world. The first likes PHP roughly the way it is - dynamic, with strong BC bias and emphasis on simplicity; The other, prefers a stricter language, with reduced baggage and more advanced/complex features.	+
-	- There's no 'right' or 'wrong' here. Both schools of thought are valid, and have a very substantial following. However, it's challenging to create a language that caters to both of these crowds at the same time - which is a constant source of contention on internals@.	+	* There are two big, substantial schools of thought in the PHP world. The first likes PHP roughly the way it is - dynamic, with strong BC bias and emphasis on simplicity; The other, prefers a stricter language, with reduced baggage and more advanced/complex features.
-	- The proposal is to create a new dialect of PHP (code named P++; name subject to change) that will live alongside PHP, but won't be bound by the historical philosophy behind the language. In other words, this new dialect could be inherently more strict, it could be more daring with BC and remove elements that are considered 'baggage' (such as short tags), and adding more complex features - especially ones that are a good fit for strictly typed languages - without having to introduce the same complexity to the PHP dialect.	+	* There's no 'right' or 'wrong' here. Both schools of thought are valid, and have a very substantial following. However, it's challenging to create a language that caters to both of these crowds at the same time - which is a constant source of contention on internals@.
-	- This is =not= a fork. The code base will be identical, the developers working on that codebase will be identical. The vast majority of the code would be identical. Only the specific points of difference between the two languages will have different implementations. It is somewhat similar to what was done with strict_types in PHP 7 - only on a larger scale.	+	* The proposal is to create a new dialect of PHP (code named P++; name subject to change) that will live alongside PHP, but won't be bound by the historical philosophy behind the language. In other words, this new dialect could be inherently more strict, it could be more daring with BC and remove elements that are considered 'baggage' (such as short tags), and adding more complex features - especially ones that are a good fit for strictly typed languages - without having to introduce the same complexity to the PHP dialect.
		+	* This is =not= a fork. The code base will be identical, the developers working on that codebase will be identical. The vast majority of the code would be identical. Only the specific points of difference between the two languages will have different implementations. It is somewhat similar to what was done with strict_types in PHP 7 - only on a larger scale.

	==== Do we really need to do all that just because some folks can't give up on short tags? ====		==== Do we really need to do all that just because some folks can't give up on short tags? ====
Line 31:		Line 36:
	==== This means doubling our development efforts. How are we going to deal with that? ====		==== This means doubling our development efforts. How are we going to deal with that? ====

-	Thankfully, it doesn't mean that at all. The vast majority of code will be shared between the PHP mode and the P++ mode.	+	Thankfully, //it doesn't mean that at all//. The vast majority of code will be shared between the PHP mode and the P++ mode - both in source and at runtime.
-	Data structures, key subsystems, extensions, web server interfaces - and mostly everything else - will be be the exact same code running regardless of whether the file being executed is a PHP one or a P++ one. The only additional development overhead will be the specific areas of difference between PHP and P++.	+
		+	Data structures, key subsystems, extensions, web server interfaces, OPcache - and mostly everything else - will be be the exact same code running regardless of whether the file being executed is a PHP one or a P++ one. The only additional development overhead will be the specific areas of difference between PHP and P++.

	It's true that it means we'd have to maintain two versions of certain pieces of code, and that we'll have some if() statements in various places - as P++ is likely to have additional checks compared to PHP. However, these are elements that would have to be introduced //anyway// if we're ever to move towards a stricter version of PHP. Moreover, since even folks in the strict crowd don't suggest that we move towards a stricter future without providing a migration path - effectively, the efforts involved with this approach and virtually any other approach are similar.		It's true that it means we'd have to maintain two versions of certain pieces of code, and that we'll have some if() statements in various places - as P++ is likely to have additional checks compared to PHP. However, these are elements that would have to be introduced //anyway// if we're ever to move towards a stricter version of PHP. Moreover, since even folks in the strict crowd don't suggest that we move towards a stricter future without providing a migration path - effectively, the efforts involved with this approach and virtually any other approach are similar.
Line 47:		Line 53:
	==== Will I be able to mix and match PHP and P++ in the same app? ====		==== Will I be able to mix and match PHP and P++ in the same app? ====

-	Yes. While we need to work out the exact mechanics, the designation of whether code is PHP or P++ will be at the file level. A single execution (request) may load many different files, and these files could be from both dialects. Code from PHP files will behave with the PHP semantics - while code from P++ files will behave with P++ semantics. Here too - this would be similar to strict_types.	+	Yes. While we need to work out the exact mechanics, the designation of whether code is PHP or P++ will be at the file level - not at the request level. A single execution (request) may load many different files, and these files could be from both dialects. Code from PHP files will behave with the PHP semantics - while code from P++ files will behave with P++ semantics. Here too - this would be similar to strict_types.

	While this may sound awkward at first - there could be very practical use cases for this. For instance - a P++ only framework that is being used by a PHP application - or vice versa. For those of you familiar with C and C++ - this is somewhat similar.		While this may sound awkward at first - there could be very practical use cases for this. For instance - a P++ only framework that is being used by a PHP application - or vice versa. For those of you familiar with C and C++ - this is somewhat similar.
Line 53:		Line 59:
	==== Does it mean PHP will no longer evolve? Will all new features go into P++? ====		==== Does it mean PHP will no longer evolve? Will all new features go into P++? ====

-	No, it just means it'll evolve differently. Strictness and type related features are likely to go just to P++, and only be available in P++ files. Bias for BC will remain in PHP (which won't mean it would never be broken - just that there'd have to be good return-on-investment cases for each such case). However - unrelated features - such as performance improvements in the engine, development in extensions, or new async-related features - will be available to both PHP and P++.	+	No, it just means it'll evolve differently. Strictness and type related features are likely to go just to P++, and only be available in P++ files. Bias for BC will remain in PHP (which won't mean it would never be broken - just that there'd have to be good return-on-investment cases for each such case). However - unrelated features - such as performance improvements in the engine (e.g. JIT), development in extensions, or new async-related features - will be available for both PHP and P++.

	==== What are the benefits of this approach? ====		==== What are the benefits of this approach? ====
Line 61:		Line 67:
	Beyond being a good technological solution - that enables us to support our entire audience in the least amount of effort - this could also bring an end to key source of contention on internals@ in recent years.		Beyond being a good technological solution - that enables us to support our entire audience in the least amount of effort - this could also bring an end to key source of contention on internals@ in recent years.

-	Finally - although most of the readers of this document are likely to be technology people - it should be noted that launching P++ that would start with a clean slate - could have substantial positioning advantages. Companies, development managers and individual developers who have ruled out PHP - are more likely to take note of a P++ launch, than of a launch of PHP 8.0 or PHP 9.0.	+	Finally - although most of the readers of this document are likely to be technology people - it should be noted that launching P++ that would start with a clean slate - could have substantial positioning/branding advantages. Companies, development managers and individual developers who have ruled out PHP - are more likely to take note of a P++ launch, than of a launch of PHP 8.0 or PHP 9.0.

	==== Aren't we risking fragmenting the userbase? ====		==== Aren't we risking fragmenting the userbase? ====

-	To a degree, we are. But at this point, it looks inevitable.	+	To a degree, we are. But this isn't a flaw of this idea - but a representation of reality as it already exists on the ground.
		+
		+	As mentioned above, there's a huge crowd out there that likes the dynamic nature of PHP, and looks warily at the attempts to make it more and more type-oriented.
		+
		+	At the same time - there's another huge crowd out there that looks at PHP and thinks to themselves "why is it evolving so slowly towards finally getting rid of this dynamic nonsense?"
		+
		+	There's no right or wrong here. Both points of view are valid. When we look at potential solutions to bridge between these two contradictory points of views, there aren't too many of them available:
		+
		+	- =Stick with dynamic PHP=. This will not be accepted by the proponents of a stricter language.
		+	- =Evolve towards strict PHP=. This will not be accepted by the proponents of a dynamic language.
		+	- =Fork the codebase=. This is a net lose option for everyone involved, regardless of how it's done. There's no technological advantage to doing that, and we don't have enough contributors to do that even if we wanted to (which we don't).
		+	- =Come up with some creative solution to cater to both audiences=. This is what this proposal attempts to do.


-	==== How does this relate to Editions? ====	+	==== What are the challenges? ====

		+	There's no shortage of challenges before we can run our first P++ app.

-	==== What are the challenges? What are the downsides? ====	+	- We need to get buy-in. That means that folks from both schools of though need to give up on a dream of having PHP be entirely dynamic or entirely typed, while disregarding those who think differently from them. This appears to be a very substantial challenge.
		+	- In order to be successful, the very first version of P++ should deal with all, or at least the majority of compatibility-breaking changes from PHP - so that developers who make the switch, won't have to reaudit/radically refactor their code once more in the future. Some have voiced concern that they may be too optimistic to do in one installment with the limited developer-power we have. We'd have to evaluate that once we have a better idea of what that list is. Note that it does not mean we need to implement any and all ideas we may have for P++ at this first version - just that we should do our very best to deal with elements that would trigger substantial code rewrite - before our first release.
		+	- Of course, the most challenging of all - we need to find a reasonable name for this new dialect.

PHP Wiki - p

faq