pplusplus:faq
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
pplusplus:faq [2019/08/12 12:09] – Move 'concerns' into a separate document, revert dynamic/weak/strong changes - "strict" means strong and static typing zeev | pplusplus:faq [2019/08/14 13:37] – zeev | ||
---|---|---|---|
Line 6: | Line 6: | ||
This is a clarifying FAQ for the idea presented on [[https:// | This is a clarifying FAQ for the idea presented on [[https:// | ||
+ | |||
+ | A [[pplusplus: | ||
Note: P++ is a temporary code name and is subject to change. | Note: P++ is a temporary code name and is subject to change. | ||
Line 46: | Line 48: | ||
==== Why not just make a perpetual PHP 7.4 LTS and be done with it, as we move to a stricter PHP 8/9? ==== | ==== Why not just make a perpetual PHP 7.4 LTS and be done with it, as we move to a stricter PHP 8/9? ==== | ||
- | There are many issues with this approach. Even if we disregard | + | There are many issues with this approach, but these are probably the most important ones: |
+ | - For the dynamic crowd - more strictness is not equivalent to progress, and as such - they don't want to see future versions of PHP forcing them in that direction. | ||
+ | - Equally important | ||
==== Will I need to choose between PHP and P++? ==== | ==== Will I need to choose between PHP and P++? ==== | ||
- | Yes and no. As mentioned above, when you install one - you'd have the other - so as far as apps go - you'd be able to run both dialects on a single server. | + | Yes and no. As mentioned above, when you install one - you' |
Line 111: | Line 115: | ||
- Of course, the most challenging of all - we need to find a reasonable name for this new dialect. | - Of course, the most challenging of all - we need to find a reasonable name for this new dialect. | ||
+ | |||
+ | ==== This is Hack all over again, isn't it? Why would it fair any better? ==== | ||
+ | |||
+ | While conceptually the motivations for both P++ and Hack are similar - there are at least two critical differences between the two - each of which is likely sufficiently big to change the expected outcome. | ||
+ | |||
+ | * Hack was/is developed by a single company, and not as an open process by volunteers. | ||
+ | * Perhaps more importantly - Hack (and HHVM) did not have PHP's gigantic distribution vehicle. | ||
+ | * For Hack, it was an uphill battle for users to even give it a try: | ||
+ | * They had to learn about its existence, and be sufficiently interested to learn more about it. | ||
+ | * Assuming they were interested enough to give it a try - they had to go through the trouble of setting it up - using entirely different methods from the ones they were used to from the PHP days (different layout, different configuration, | ||
+ | * With P++ - this is a radically different story from the ground up: | ||
+ | * Every user of PHP (starting with 8.0, or whenever we make it available) - will have it available on their servers. | ||
+ | * This in turn means that virtually anybody running a Linux distro, a recent version of WAMP, a recent version of MAMP - millions of servers and development workstations will have access to P++ without having to do anything proactively. | ||
+ | * In terms of awareness - since P++ will be a big part of the " | ||
+ | * Of course, it doesn' | ||
Line 116: | Line 135: | ||
Arnold Daniels compiled [[https:// | Arnold Daniels compiled [[https:// | ||
+ | |||
+ | Some of them are addressed here: | ||
+ | |||
+ | === Converting PHP code to P++ code is not trivial === | ||
+ | |||
+ | That may be true - but it ultimately depends on what we decide to put into P++. This proposal assumes that the contents of what we'd want to do would be similar, regardless of whether we deliver it using declare()s, Editions or a unified P++ dialect. | ||
+ | |||
+ | === PHP tooling will not support P++ === | ||
+ | |||
+ | It's important to understand that technologically - it'll actually be slightly simpler for vendors to support P++ vs. having to support granular declare()s or an unlimited amount of editions. | ||
+ | |||
+ | |||
+ | === It's not possible to do a cleanup without breaking PHP compatibility === | ||
+ | |||
+ | That is true - but that is actually a good reason to consider introducing this new dialect, and not vice versa. | ||
+ | |||
+ | Regarding the specific examples brought up by Andi: | ||
+ | * Removing array() will have no impact on compatibility of P++/PHP - it's just syntactic salt for the more modern [] syntax. | ||
+ | * Removing the global namespace for functions (if we do it) will only affect P++ code (i.e., access to it would be removed) - it will still be there in PHP code. | ||
+ | |||
+ | It's important to stress that neither of these ideas were discussed to date, and may or may not be proposed for future inclusion in P++. | ||
+ | |||
+ | === The popularity of Python doesn' | ||
+ | |||
+ | This document - and the proposal in general - does not claim to suggest that strong/ | ||
+ | |||
+ | |||
+ | === Is there really a need for a different dialect? === | ||
+ | |||
+ | One of the axioms that many in the ' | ||
+ | |||
+ | At the same time - many others pro-strict folks are more pragmatic, and want to simply add optional strictness - along the lines of strict_types. | ||
+ |
pplusplus/faq.txt · Last modified: 2019/08/14 13:47 by zeev