I envy the fast development cycles the PHP language developer team is doing. From five years until now, I’d say PHP has had a completely overhaul since the time I stopped web development.
As a long-time PHP developer, its way too fast. We're forced to constantly upgrade for features that don't really matter for most uses, but aren't backwards compatible.
As someone maintaining multiple 10+ year old PHP applications - after the migration to 7 things have been super easy/simple. Especially if you get Rector [0] involved.
Whether it’s easy or not in your particular space isn’t the problem. The problem is that it breaks period.
Some applications might be easy to upgrade. Others will not. You are forced to do work, because for some minority it feels nicer when they get to use that new feature. And it has to look a certain way, no matter the cost! Some of the stuff that’s comming will be even worse.
The even bigger issue is that your underlying tool breaks, which has an impact on dependecies as well. Foo needs version N now, but you also depend on Bar which only works with N-1.
You are under no obligation to upgrade your php version as soon as released without being able to plan for it. PHP 8.1.17 was released alongside 8.2.4 for exemple.
I think PHP is missing some kind of LTS which adds another year (or two) of support or some more stability. I wanted to say Dotnet has a longer cycle, but they have 2 years for regular and 4 year for LTS releases, while PHP has 3 years for every minor. So not that much better.
However, I had to migrate some 30k LOC app from Dotnet 3 to 6 this year and it was quite straight forward. Not that many thinks broke, and when then they were in the bootstrapping of the app.
I'm not that much into PHP anymore, so my take might be wrong. I wouldn't like to upgrade each year to a new version which breaks syntax. I would be ok to migrate every 3 or 4 years from LTS to LTS.
PHP is mostly run on Linux, and the LTS version of PHP is essentially the one shipped with your distribution. They backport most security fixes.
To use the latest PHP 8.2 version Debian or Ubuntu users need to add an external package source, meant specifically to be "on the edge" for PHP, deb.sury.org
There's a point to discuss around the lack of any official LTS version.
But GP comment is not that, it reeks of "old man yells at cloud" with zero mention of what is an issue and what isn't.
5.x -> 7+ was a pain, mainly down to those projects being without composer or other really suspect practices that need fixing at the same time. Much of the actual issue was due to particular string concatenation methods or the mysql_* lib which is easily shimmed to something like PDO.
I understand but like I said, official PHP version in your distribution packages kind of act like an LTS anyway, people who use 8.2 are using Sury or similar.
> 5.x -> 7+ was a pain, mainly down to those projects being without composer or other really suspect practices that need fixing at the same time. Much of the actual issue was due to particular string concatenation methods or the mysql_* lib which is easily shimmed to something like PDO.
That's what I meant in my other comment, while it's true, mysql_ was already being removed in favor or PDO in PHP 5's time, and PHP 5 to PHP 7 was almost a decade of developpement, so I don't think it's fair to put these issues on "too fast a developpement cycle".
What do you mean? Backwards compatibility in PHP is amazing. I have several large projects that I've been working on for 15+ years, and upgrading to newer PHP versions has been a dream.
What kind of things are you having problems with in regards to backwards compatibility?
While "abandon those projects" doesn't help someone who developped something with it and need to keep them updated, the fact is that you can just keep using the older version of the library while you do your update it works just fine on newer PHP, AND pretty much any decent sized projects doing such a switch has a large transition period where they support both, AND tooling to automate such upgrade exists AND we should be very happy about removing code from comments.
Most big projects offer a large transition period. And their "older" version works just fine on latest PHP versions anyway, so you have the time to do your upgrade. And the tooling to make such upgrade is very stable and well working, rector does 99% of the job.
I love PHP, and think updates over the last several years have been relatively painless. But it doesn't feel like it's always been that way over the last 15 years.
You're going to need to give exemples here. Upgrading has been super simple.
The one time you actually may have had to work on things was with PHP 7, but that's because they finally removed things that had been deprecated for years, some for over a decade, and all of them were security risks or massive code smell anyway.
The one thing with PHP 8 was the removal of dynamic propery, and again that's a massive code smell that was holding the language back. Any code still using it when PHP 8 released was either written over a decade ago, or something that has way more issues than that with upgrading.
I am surprised there is no discussion in the PHP community to introduce a module system.
The current solution for code reuse (use longer class names to avoid clashes, we help you with syntactic sugar called "namespaces") is the wrong approach imo.
Composer autoloading and the PSR-4 naming convention works just fine, since you have to separate the class names with some kind of information about the developer, followed by the name of the class. Java uses a similar naming scheme too ("org.apache.commons.SomeClass" etc.) though autoloading is specific to PHP.
I'm curious as to why you consider autoloading over PSR-4 namespaces as insufficient.
Version conflicts on shared transitive dependencies is a real problem, to the point that there are tools available to library authors that allow them to rename their dependencies to be under their own namespace to avoid collisions.
If two packages I require depend on incompatible versions of some third package, there aren't any easy ways for me to resolve it.
This problem exists because of the global nature of PHP namespaces.
People complain about the size of node_modules. I think Composer's approach to find a common set of dependencies that satisfy all version constraints keeps things lean.
To begin with, the fact the "module" system is tied to classes is a horrible design flaw. (Also in Java, but Java leans into it - PHP still has functions and lots of stuff is clearer as functions.)
AFAIK this only works if the function has already been loaded for some other reason (i.e. in the same file as a class or an explicit require). I do cop to not having used PHP recently, so maybe 8 fixed it?
At least in the PHP I'm familiar with, nothing "happens" at `use` time; the first time you call a method on a class it autoloads. The autoloader is then what does the work of finding and requiring the file. No class, no autoloader.
PSR is intended for framework authors, and I strongly think it was one of the best things that happened to the php ecosystem. The PSR-7 http messages alone have made SO MANY things compatible at once, it’s incredible. And it works so well that most php developers aren’t ever aware that PSR underpinnings power most dependencies they use!
Genuine question, why are you version matching PHPUnit? It's arguably one of the most backwards compatible software packages still being actively developed. I have multiple projects using phpunit version (*) with no issues.
I will readily admit that 99% of my assertions are some variation of `$this->assertEquals()`
Working around underlying problems with tools and conventions is something that is fine when you get paid for your time.
As a maker, I prefer a clean stack. So that its complexity does not slow me down. Workarounds make development slower and slower, the more it becomes a giant hairball of workarounds and workarounds around workarounds.
In Python and JavaScript, I don't need those workarounds. Would be awesome if PHP catches up.
> The current solution for code reuse (use longer class names to avoid clashes, we help you with syntactic sugar called "namespaces") is the wrong approach imo.
But PHP namespaces and autoloading via composer ARE the community accepted way to handle namespacing. The ecosystem is so large developers aren't going to move to a different module system at that point. Especially when composer is the defacto package manager for PHP.
Namespaces and modules are orthogonal, you can support both like Typescript.
Your solution works, but unfortunately not something that has any community support. I proposed something similar a year ago but use classes instead because classes seems to be the internal building block in PHP.
For both our solutions is would relatively easy to add a shim to older PHP versions.
module.php
<?php
return new class {
public const MY_CONST = 47;
private const MY_PRIVATE_CONST = 127;
// with PHP 8.1 you also have readonly properties
public string $myPublic = 'foo';
private int $myPrivate = 17;
public function helloWorld(string $name): void
{
echo "Hello, World {$name}!";
}
};
main.php
<?php
final class ModuleException extends Exception {
}
function module(string $name): object
{
static $modules = [];
if (isset($modules[$name])) {
return $modules[$name];
}
try {
$module = @require $name;
} catch (Error $error) {
throw new ModuleException("No such module {$name}", 0, $error);
}
if (!is_object($module)) {
throw new ModuleException("Module {$name} is not an object");
}
$modules[$name] = $module;
return $module;
}
$my = module('module.php');
$my->helloWorld('Module system');
$other = module('module.php');
assert($my === $other);
Honestly, as a PHP développer, the node's module system impress me A LOT.
I went on several projects that had not kept their dependencies on the "edge version". For some, it was more than a year of work just to be able to move from php7 to php8.
PHP dependencies are so intertwined that for projects that abuse and use more than a reasonable amount (aka their ability to invest time keeping them and the code using it up to date) the update process can become a nightmare of complexity.
Node's module system let you move each dependency at it's own pace. This is such a breath!
The problem is that when you only know of the solution of your ecosystem, it's hard to see the added value you miss out.
My recommendation for every PHP projects that uses external libraries is to use your own wrapper function/class to minimize contamination of the project.
If you use a framework then try to write all your own code outside of the framework and pass in all needed framework data as arguments to your own classes/functions.
However, what I was speaking about is the version handling of (sometimes direct but mostly) indirect dependencies.
The domain of `composer why` and `composer why-not`.
One if the most speaking example I can think of is: if two libs depends on guzzle 5, then you can't update only one on a version that depends on guzzle 6: you must upgrade both at the same time. Each to an intercompatible lock on guzzle version.
Yep. Laravel drags the otherwise great php ecosystem into the dirt. Other than that, there’s heaps of great libraries and quality development out there.
