- Date: 2019-08-12
- Author: Arnold Daniels
Concerns about the P++ idea
Concerns about the P++ idea are presented in this document.
The dialect won't be limited to loose vs strict
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
In 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).
Indeed. The directive may make operators more strict in what they accept, but it should avoid changing the semantics. Concretely, we must have either:"120" > "99.9"; // true
or:"120" > "99.9"; // TypeError
Anything else will bring confusion.
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
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 a partial or complete rewrite.
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 tools. Those maintainers might choose not to invest the time for support until P++ has a substantial user base. On the other hand, devs might choose not to P++ until it has proper tooling support.
It's not possible to do a cleanup without breaking PHP compatibility
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…
Removing things like references, array() and the global namespace for functions would make it impossible to use PHP functions from 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
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's 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 brand, with 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.
The popularity of Python doesn't have to do with typing
In the case of Python, it seems to be the numerical, scientific and linear algebra libraries that's driving its popularity.
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 a new dialect really necessary?
I feel like both hardcore camps Zeev is describing are too way off base and want basically impossible. The 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.
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 statement. This would make PHP a weak dynamically typed language without
strict_types and a strong dynamically typed language with
New and more strict data structures could be introduced. Attempts for this have been made through the SPL and 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.
I don't see these (or Generics which you also mentioned) as being inherently incompatible between more/less strict codebases.
New feature and new core functions (like a new string library) would not break backward compatibility.