[TekMol]

Composer adds even more tooling around the fundamental problem that PHP does not have modules.

And it does not do away with the problem that you have to preemptively wrap everything in classes and add a LongUniqueStringToHopefullyAvoidCollisions via the "namespace" and "use" keywords to all your classes to hopefully avoid name clashes in the future.

[forgetfreeman]

PHP not having modules is a non-issue. Proof: It's done fine for several decades without it. If you're running into namespace collisions in your codebase frequently enough to demand a language change to help get your shit together I don't even know what to tell you.

[tored]

It is not a non-issue. You can run into naming collisions by just using two different composer dependencies where each dependency depends on the same library but different major versions.

[shakesbeard]

That's just not true. It's not JS. Composer will install exactly one version of every package. If your dependencies have incompatible dependencies themselves, then Composer will refuse to install the package. And this fact has led to PHP packages actually being maintained and kept compatible with each other. Of course, sometimes you run into dependency issues, but it's worth it because you'll always have quite clean, flat and small vendor directory. Compared to the node_modules horror it's great for maintenance.

[tored]

This can definitely be an issue and it was when Guzzle released a new major version every month.

Also when working with projects that are 10+ years and lines of codes a million you will run into this. Sure you can always fork and move the library to another namespace, but that is extra work.

Modules are vastly superior to namespaces, with modules it is the caller that decides the symbol, with namespaces it is the callee.

Another problem with namespaces in PHP is that you can’t put anything into it, like a variable, it is not like namespace in C++. Namespace in PHP is just name added to the class or function name, kind of fake. Don’t get me wrong, it was a pragmatic solution to a real problem and it worked for what it tried to solve, make it easier to share code.

Modules could be elegantly solved in PHP by reusing the internal concept for a class (how it is with enums and interfaces)

Modules would also make it easier to unit test code, because you will not need to worry about a symbol already have been loaded and can’t get unloaded.

With that said I don’t think it the most important feature to focus on, there are others that give more bang for the buck, like string templating and operator overloading.

[phplovesong]

So PHP forces you to put everything in class? Thats hilarious!

[tored]

Yes, because functions can’t be autoloaded and you can’t put variables and constants inside a namespace. But it isn’t hilarious, it is because of legacy.

Now there are proposals to fix function autoloading but it won’t fix variables and constants.

One way to do it better is to implement modules.

[phplovesong]

Thats why PHP code looks like Java. EVERYTHING is wrapped in a class, because of the shitty packaging PHP currently has. Namespaces are weak and can be inconsistent. Also the stdlib has no namespaces? Wtf?

[forgetfreeman]

You're pointing a finger at the wrong villain. Laravel's your culprit not core PHP. I have no idea what mind-altering substances that crowd got into when they decided to objectify everything all the time, but it isn't a hallmark of either the language or good coding practices and the result is so hard to debug it requires it's own toolchain. Fun Fact: Drupal's core team threw a big chunk of it's community developers overboard switching to this bullshit. Net result: they bricked the project's credibility listening to the wrong people and lost a bunch of market share and mindspace because of it. A shame too, the project could have credibly challenged Wordpress if they'd gone another way.