pplusplus:faq

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Next revisionBoth sides next revision
pplusplus:faq [2019/08/12 11:54] – Added quotes for concerns jasnypplusplus:faq [2019/08/13 05:43] zeev
Line 6: Line 6:
  
 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.
 +
 +A [[pplusplus:concerns|list of concerns]] about this idea has been compiled by Arnold Daniels.  Some of them are addressed [[pplusplus:faq#what_are_the_general_concerns|here]].
  
 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 83: Line 85:
 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: 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 loose (aka weak) dynamic PHP**.  This will not be accepted by the proponents of a stricter language. +  - **Stick with dynamic PHP**.  This will not be accepted by the proponents of a stricter language. 
-  - **Evolve towards strict (aka strong) dynamic PHP**.  This will not be accepted by the proponents of a loosely typed language.+  - **Evolve towards a stricter PHP**.  This will not be accepted by the proponents of a more dynamic language.
   - **Fork the codebase**.  This is a net loss 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).   - **Fork the codebase**.  This is a net loss 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.  It does that while keeping the project itself unified, and while ensuring perpetual interoperability between the two dialects - so that while there'll be some level of fragmentation, it will be the minimal one possible that still addresses everyone's primary needs.   - **Come up with some creative solution to cater to both audiences**.  This is what this proposal attempts to do.  It does that while keeping the project itself unified, and while ensuring perpetual interoperability between the two dialects - so that while there'll be some level of fragmentation, it will be the minimal one possible that still addresses everyone's primary needs.
Line 112: Line 114:
  
  
 +==== This is Hack all over again, isn't it?  Why would it fair any better? ====
  
-==== What are the general concerns?  ====+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.
  
-=== The dialect won'be limited to loose vs strict ===+  * Hack was/is developed by a single company, and not as an open process by volunteers.  Even if the vendor that's behind it is gigantic - companies and individuals were often reluctant to standardize on a such a platform. 
 +  * 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, different everything). 
 +    * 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.  You will not have to install anything, or set anything up - it will simply be there. 
 +      * 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 "What's new in PHP 8" - it will enjoy free marketing like Hack could only dream of - similar to the PHP 7 performance splash (few in the PHP world are unaware of it). 
 +      * Of course, it doesn't mean that everyone will want to start using it - but the barrier to entry with P++ is many orders of magnitude lower than what Hack to face.
  
-Progression of PHP may halt as any substantial changes are be opted to be done in P++ only. With the ''strict_types'' directive, it's clear that it's limited to loose vs strict types. The difference between PHP and P++ could be very broad and unintuitive. 
  
-=== Semantics should not be changed based on a flag ===+==== What are the general concerns?  ====
  
-In [[https://externals.io/message/106063|the discussion of the strict operators RFC]], serious concerns were raised for changing the semantics of an operation based on a directive (or any kind of flag).+Arnold Daniels compiled [[https://wiki.php.net/pplusplus/concerns|a list of concerns]] about this proposal.
  
-<blockquote>Indeed. The directive may make operators more strict in what they accept, but it should avoid changing the semantics. Concretely, we must have either: +Some of them are addressed here:
- +
-<code php> +
-"120" > "99.9"; // true +
-</code> +
-or: +
- +
-<code php> +
-"120" > "99.9"; // TypeError +
-</code> +
-Anything else will bring confusion. +
- +
-—Claude +
-</blockquote>+
  
 === Converting PHP code to P++ code is not trivial === === Converting PHP code to P++ code is not trivial ===
  
-For applications that do not rely on implicit typecasting, but use explicit casting or functions like those from the filter extension instead, not code needs to change to switch to strict type checking using ''strict_types''. +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.  The premise of this proposal is that there'large group of people in the PHP space that //want// to change PHP to be substantially different from the way it is today - making it increasingly more strong- and statically-typed.  It also assumes that this isn't bad thing - as long as don't treat it as zero sum game with those who want to keep PHP more dynamic and loosely-typed as it presently is.
- +
-The concern is that the syntax of PHP and P++ will grow apart to such an extent, that converting a PHP application to P++ would not be possible without partial or complete rewrite.+
  
 === PHP tooling will not support P++ === === PHP tooling will not support P++ ===
  
-There are a lot of tools available for PHP developers, like IDEs, testing frameworks, etc. Supporting both PHP and P++ requires effort from maintainers of those toolsThose maintainers might choose not to invest the time for support until P++ has a substantial user baseOn the other hand, devs might choose not to P++ until it has proper tooling support.+It's important to understand that technologically - it'll actually be slightly simpler for vendors to support P++ vshaving to support granular declare()s or an unlimited amount of editions There's no reason to assume that it'll be treated any differently than if similar features/changes are introduced and delivered using a different mechanism. 
  
 === It's not possible to do a cleanup without breaking PHP compatibility === === It's not possible to do a cleanup without breaking PHP compatibility ===
  
-<blockquote>So many times I have thought “is it time to just take an axe and simplify it and do a cleanup?”I actually don’t think we lack many features but rather lots of stuff I would dump like references, array(), global namespace for functions(?), type juggling in areas where we should be stricter, etc...+That is true - but that is actually a good reason to consider introducing this new dialect, and not vice versa Many proponents of strict also want to make bigger leaps in terms of breaking downwards compatibility.  Today - there's no other option except for a zero sum game with folks who may not be so fond of breaking BC (especially if it'in order to make PHP stricter) There have been numerous instances of that in recent times, and it seems many more are in store for the future.
  
-Andi +Regarding the specific examples brought up by Andi: 
-</blockquote>+  * 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.
  
-Removing things like references, array() and the global namespace for functions would make it impossible to use PHP functions from P++. +It'important to stress that neither of these ideas were discussed to date, and may or may not be proposed for future inclusion in P++.
- +
-=== Compatibility would only be one way === +
- +
-Introducing new data structures that only exist in P++, could make it impossible for PHP library to use P++ libraries. +
- +
-=== P++ would have to do branding from scratch === +
- +
-<blockquote>What would be the plan to boost or change the reputation? How are you going +
-to find P++ in Google? How are users searching for things with PHP and P++? +
-What'the documentation going to look like for two languages that share so +
-much? Specifically from a marketing POV splitting up the language into two +
-makes no sense at all. Given PHP has no unified marketing message or a +
-dedicated department it is much better to use the existing brandwith all +
-its positive and negative perception and just keep rolling with it. +
- +
-A strategy to change the security or any other perception of PHP is solely +
-a marketing, teaching and persistence issue. As you say the language is +
-already the fastest dynamic language with the best runtime. But "starting +
-over" with 0 brand name and perception is much harder problem than changing +
-the existing brand, and its not at all technical challenge. +
- +
-Benjamin +
-</blockquote>+
  
 === The popularity of Python doesn't have to do with typing === === The popularity of Python doesn't have to do with typing ===
  
-<blockquote>In the case of Python, it seems to be the numerical, scientific and linear algebra libraries that's driving its popularity. +This document - and the proposal in general - does not claim to suggest that strong/static typing is a good or a bad idea It purposely doesn't take sides on which side is "right" What it does do is acknowledge that there are two substantially opposed schools of thought for PHP users - and provides proposal on how the project can evolve to address both of them in an efficient and productive manner That said - clearly, there are lot of people who //think// a strongly-typed PHP would be better choice, so having that option may indeed increase its popularity.
- +
-Peter</blockquote> +
- +
-The popularity of Python is rapidly increasing at the cost of the popularity of PHP. Python is praised with simplicity. However, is uncertain to what extent the popularity is related to simplicity, and specifically typing, and to which is this related to better libraries (both core libs and user libs). +
- +
-=== Is new dialect really necessary? === +
- +
-<blockquote>I feel like both hardcore camps Zeev is describing are too way off base and +
-want basically impossibleThe BC crowd is just being unreasonable and only +
-the tech that evolves realistically survives. You cannot have the BC cake +
-and eat it, at some point you have to upgrade and update your application +
-code. +
- +
-The "upgrade everything, BC be dammedcrowd also needs to chillIf you +
-are so impatient - there is Go, NodeJS with it's JavaScript/TypeScript, +
-etc. Right now PHP does has somewhat of a plan and direction it is going, +
-it is going at decent pace - not too slow, not too fast. +
- +
-Arvīds Godjuks +
-</blockquote> +
- +
-As an alternative, we could extend the effect of ''strict_types'' to throw a ''TypeError'' to most places where implicit type casting is done based on the context of the statementThis would make PHP weak dynamically typed language without ''strict_types'' and strong dynamically typed language with ''strict_types''.+
  
-New and more strict data structures could be introduced. Attempts for this have been made through the [[http://php.net/spl|SPL] and [[http://php.net/ds|Data Structures]] extension. However, support for this in both core libraries, extensions, and user libraries has been limited. New native types could prove to be more successful. 
  
-Functionality that's being deprecated and removed or unbundled is rarely used. The removal of ''php.ini'' settings makes PHP more uniform. The effort of switching from PHP 7 to 8 shouldn't be much more than the effort needed to switch from PHP 5 to 8.+=== Is there really a need for a different dialect? ===
  
-<blockquote>I don'see these (or Generics which you also mentioned) as being inherently incompatible between more/less strict codebases.+One of the axioms that many in the 'strict' camp appear to believe in, is a more strongly-typed and a more statically-typed language means progress - and that the main question is how we can deliver on it.  Can we do it in PHP 8 - while keeping the dynamic crowd on a legacy 7.4 version?  Should we do perhaps do it more gradually by releasing changes every few years, until we get to where we want to be?  For that crowd - it needs to be clear that for people who prefer dynamic, loosely-typed languages - strong & static typing aren'progress - and it doesn't matter if it happens overnight or over the course of a decade.
  
-Sara</blockquote>+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.  This, arguably - can be called progress - it's not regressive for anybody, and it does provide progress to folks who prefer a more strongly-typed statically typed language.  This will likely be the direction we go for - which means that we'll already have different dialects available anyway.  It's really a matter of whether we'd have 2^N dialects (granular declare()s), N dialects (Editions), or 2 (PHP/P++).
  
-New feature and new core functions (like a new string library) would not break backward compatibility. 
pplusplus/faq.txt · Last modified: 2019/08/14 13:47 by zeev