PHP plus: P++ proposal would create a stricter dialect

It's not a fork, but a stricter version that could leave compatibility baggage behind and add new features more easily

A new dialect of PHP, code-named P++, could be developed as a stricter variant of its dynamic predecessor, with more advanced features and less baggage.

The proposal, being floated in the PHP community by PHP cofounder Zeev Suraski, would have P++, or whatever it is eventually called, living alongside PHP but not bound by PHP’s historical philosophy. P++ would not be a fork, but it would be inherently more strict and could be more daring with backward compatibility.

Elements now considered “baggage,” such as short tags, could be removed while complex features, especially ones for strictly typed languages such as strict operators or typed variables, could be added without introducing the same complexity to the PHP dialect.

Like PHP itself, P++ would predominantly be for server-side web development. The planned PHP 8 release already is expected to extend PHP beyond web development, with a just-in-time engine and interoperability with C/C++ libraries.

The vast majority of code in PHP and P++ would be identical. Most code would be shared between PHP and P++ nodes both in source and at runtime. But they would have different implementations. Binaries will be identical.

What is not clear yet is how a file would be marked as a P++ file. It would probably have a special header at the top. Builders also could find ways to mark entire namespaces as P++, so the frameworks do not have to mark each file as P++.

Data structures, web server interfaces, key subsystems, and most everything else will be the exact same code regardless of whether a file is executed as PHP or P++. Still, two versions of certain pieces of code would have to be maintained. And P++ is likely to have additional checks compared to PHP. Developers could mix and match PHP and P++ in the same app. Both dialects could be run on a single server.

If P++ happens, it would mean a different evolution for PHP. Strictness and type-related features are likely to go in P++. Bias for backward compatibility will stay in PHP. Unrelated features, such as performance improvements in the engine or developments in extensions, would be available in both P++ and PHP.

Zuraski points out potential options for the P++ language:

  • Staying with a dynamic PHP, which would not be accepted by proponents of a stricter language.
  • Evolving toward a stricter PHP, not acceptable to proponents of a more dynamic language.
  • Forking the codebase, a net loss for everyone involved.
  • Devising a solution to cater to both audiences, which is what the P++ proposal attempts.

Concerns about the P++ proposal include:

  • Converting PHP code to P++ would not be trivial. How true that is will depend on what ultimately ends up in P++.
  • PHP tools will not support P++. But it could be simpler for vendors to support P++ rather than support granular declare()s or an unlimited amount of editions.
  • Breaking of PHP compatibility. But doing so via a new dialect rather than breaking PHP itself could be more palatable.

P++ would differ from Facebook’s Hack language, which was built on PHP, in that:

  • Hack was developed by a single company.
  • Hack and the accompanying HHVM virtual machine do not have PHP’s large distribution vehicle.

Copyright © 2019 IDG Communications, Inc.