> On Jul 1, 2024, at 1:07 PM, Dusk <d...@woofle.net> wrote: > > On Jul 1, 2024, at 09:22, Mike Schinkel <m...@newclarity.net> wrote: >> 2. Autoloading effectively necessitates that every symbol be in its own >> separate file. > > How so? While Composer "recommends" PSR4 autoloading with one class per file, > other configurations are entirely possible,
I spoke inartfully, sorry. The culture of projects throughout the PHP ecosystem has resulted in most projects being one class per file, and there have not evolved any defecto-standard tools for creating those classmaps further ensuring PSR4 ubiquity. > either with Composer's autoload.classmap (which uses a precomputed class -> > filename table), or with a custom autoloader. And, refer back to reason #1 to hate autoloading in PHP. > On Jul 1, 2024, at 1:28 PM, Arvids Godjuks <arvids.godj...@gmail.com> wrote: > > But that is why interoperability in PHP world is so high. When it was > introduced, it allowed enabling autoloading for most code bases out there > regardless of what their structure was and still is. Sure, you have to be > careful how you do it, but that is also not really a userland concern - most > of those have been implemented once and then almost never touched :) The > community has settled on a general approach since naturally and that's how > vast majority of people write their code. Buggy code is buggy code, it really > has not much to do with the autoloading and with how people write buggy code > :) You are blaming the hammer for user trying to nail the screw into wood :) Two things can be true at the same time. Something can have a historical benefit but not be ideal moving forward when compared to potential future alternatives. The major benefit that autoloading has today is inertia. Yes, that's a huge benefit. But that does not make autoloading beneficial. > You can already sidestep autoloader by adding a require statement to any file > and loading everything without triggering autoload. There is not a standard way to sidestep the autoloader that has majority support in 3rd party packages. It's a roll-your-own thing. > It's far more powerful in userland because it allows people to do whatever > they want with it if they do not like the standard autoloader(s). The only reason people think about how they want autoloading to work is because they have to. Technology is supposed to evolve to eliminate rote and low-value add tasks. By the same token I could say we should introduce the ability in userland for people to modify the implementations of standard library functions so people could do whatever they want with it if they do not like the standard implementations. But clearly that latter would be crazy talk. > That's just how PSR-4 standard was written and works, and it's a good default > for a reason. On small projects - sure, I can see it being overkill. But I > haven't worked on a small project in a decade and I rarely have that little > code in one file that I would want to stuff all together in one file. I do > use PHPStorm, so it is very adapted to how most PHP projects are and provides > excellent navigation abilities that fit the PSR-4 and that way of structuring > projects. Vast part of the community uses it. It's a standard in a lot of > companies for a reason. Again, I will say this is Stockholm syndrome. > See my reply to autoloading things above - you can eliminate the autoloader > triggering easily in probably 15-30 minutes flat. But to do so there is not one single way that is reality standard. So I have to own maintenance of that low-value code. > There are aspects to this that go beyond just technical aspects. Wherever > when implementing autoloading people were secret geniuses, stumbled into it > accidentally or just had practical needs themselves that they just > implemented in this way - it has been a major turning point in PHP's life and > has transformed the ecosystem into what it is today together with the rise of > the composer package manager. I have seen people talk about visibility in > namespaces, package concept and all that, but every time it was building upon > existing autoloading mechanics - some adding capabilities to them, modifying > them, having new type of autoloader. But I have never encountered anyone in > this community in 20 years i have been an active part of it to propose a > radical change like this That is probably because you all have been working mostly in PHP and not experiencing better alternatives. BTW, NodeJS/Javascript is NOT a better alternative, IMO. Besides, what I proposed earlier was not a "radical change." Characterizing something as "radical" is just a rhetorical tactic used to discredit said thing. What I proposed was very incremental and would allow all existing code including autoloaders to co-exist with a module/package concept. Not radical. > and I'm fairly certain after keeping up with the thread that it is almost > universally not what people want. Most people just want the toolbox be > "finished" so to speak, not get a completely new one in addition that has no > compatibility with the old one. I get it. I am no longer proposing an alternative to the autoloader. PHP developers are comfortable with autoloading and that is that. But that does not mean that I cannot tell you and others the emperor has no clothes in hopes that people eventually see that there can be better alternatives. -Mike
