“ Also, it doesn't have to be black and white - ORM or no ORM
The sad state of the php world is that there is no other option but to use it. If something is on fashion then it _must_ be adopted. Writing your own is considered insanity and so is taking a different path than the mass, regardless of for good reason or not.
I appreciate your passion for php and i like our otherwise enjoyable debate, but instead of projections and a misuse of the term “assume” i would appreciate counter arguments.
All good code starts with the individual. In the PHP world it starts with the collective, not much room for creativity on the assembly line, and any such attempts are met by endless debates over petty code reviews - many of which can be replaced by linters.
Of course i wrote in large teams, thats why i know that a large codebase with hundreds of people working on it is usually a sign of either bad practice (the monolith that grew too much) or high turnover (php work places are often toxic and filled by mediocrity).
Instead of ignoring my advice on maintainability, consider breaking your code into smaller chunks and write less code that doesnt solve self inflicted issues (ie your complex queries across hundreds of tables, dtos that dont solve much, custom functions for stuff that can already be done in sql). Once you do the above you wont need all of the overhead you describe and so specific to php.
My code usually lasts a good number of years, often even after i’m no longer working on it. It’s difficult to break and easy to maintain. At least thats the feedback i get from repeat clients. The teams i lead have easily delivered code that generates returns in the billions. All without the mess you describe.
There is merit in this - once a php dev does get to know the language they move away to other languages. So you are indeed left with people that dont know the language.
Totally agreed re keeping an open mind. But after having used all the niceties you describe i understood that php itself is a fractal of poor design and practices. Gave up on using literally everything you described and ended up writing better code at a fraction of the time.
I do recommend reflecting on things as not knowing everything goes both ways.
This brings fond memories of my early stages where i became fond of the method chaining pattern. I became fascinated by it when using doctrine.
However the code you pasted is horrible and easily replaced by sql. Not only does someone else need to learn your custom logic functions and dtos but they also need to read stuff like “ x.relation.relation.relation.value”. I see your point in regards to dtos “automagically” updating queries, but if you have queries laying around everywhere thats another code smell. Basically, this is solving artificial problems.
The code you pasted can be replaced by a trivial query, which should table columns be renamed (i mean whats the frequency of that anyway, potentially another code smell), it would take less to update than updating all the dtos custom functions and the sausage code.
Edit: i am not belittling you, my point is that the code above solves self inflicted issues that could be written in a basic sql query with bound params. Basically you spend twice as much to write and maintain code that is simply not necessary.
Hold on, we are talking php here. There is no code compiling.
Either way what you are describing sounds like instead of maintaining sql code you prefer maintaining orm code. DTOs are just overhead.
I gave up on all these after 15 years of using them because the benefits are precisely zero (except for migrations). Similarly with typescript, if you are competent enough with js and as a programmer you dont need it. The web can overkill itself perfectly fine without a scripted language that transpiles to a scripted language.
Perhaps its just me, i rarely make typos and when i do the linter or ide catches them early on. In highschool they made us keep track of variables and their types with pen and paper and as a result i always know what type my var is. I was also taught that just because you can it doesnt mean you should. So i dont write a dto for transferring an object to a different api. It’s just a waste of time, specific to PHP devs.
Edit: the type of code you pasted is horrible to maintain. You can achieve that with less sql.
But you can already write amazingly complex queries in sql, and structure them as objects directly using pdo. If there are hundreds of developers working against the same codebase then that codebase is too large. If you need to query hundreds of tables in one go you need to consider denormalisation or using a document storage.
You are right about the reasons there are so many amateurs in the php world. But i disagree with the statement that they become professionals over time. If you keep doing the same wrong thing over and over you just become better at doing the same wrong thing over and over, many being just old junior developers. Add the fresh supply of amateurs entering the php job market each year and you are stuck.
There are elites among php, you may be one of them, but having interviewed hundreds believe me the quality is very very low.
Thing is if you understand php you dont really need a framework. Sure composer packages are a must to avoid rewriting whats out there, but a framework not so much. When i conducted interviews i was shocked at how many php devs had no clue about what an sql injection is, they almost all answered “the framework does it for you” and it was such a basic thing.
This stems from the fact that many in web dev are not really engineers. There’s a lot of reinventing the wheel and cult like following of various tech influencers. Instead of extending existing libraries people just fork repositories, add minor changes, and advertise them as new. A lot of architectural patterns are just a soup of concepts thrown around without proper planning or understanding of dry or solid.
The issue with php is the type of developers that use it and bloated frameworks. Nearly all developers still debate wether to use setters and getters and have no clue how to use the language itself, as a result using over engineered frameworks. The language itself is nice but is swamped by amateurs.
Specialised search engines are the future in my view. Google is an ocean of data great for generalised search. But as soon as you want to narrow down to a specific domain it’s mostly noise - in my personal experience.