Hacker News Reader

Comment by supriyo-biswas | Hacker News Reader

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.

View on HN

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.

I have encountered this once in my career, it’s pretty rare.

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.)

…and you can have namespaces for functions and import namespaced functions just fine.

You can namespace them, but you can't `use` them or otherwise autoload them.

Are you sure? I've definitely written a `use` statement to import a function.

https://www.php.net/manual/en/language.namespaces.importing....

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.

PHP 8 hasn't fixed function autoloading, and Composer still has hacks like you can specify function containing files it will always load.

"works just fine" - obviously never watched xdebug shart the bed while composer tries to version match phpunit.

A module system and less reliance on PSR the better. Why exactly does PSR still exist?

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!

> PSR is intended for framework authors

That's my problem with it. It should be focused on what's good for developers. Not what makes it easier to overengineer the next flavour of the month.

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.

Reply on news.ycombinator.com