4 ms·

I don't think that's fair, it's not a rant and not specifically targeting OO and frameworks. It's targeting that mindset of modern PHP = PHP with a lot of unnec

by onli 6y ago

I don't think that's fair, it's not a rant and not specifically targeting OO and frameworks. It's targeting that mindset of modern PHP = PHP with a lot of unnecessary abstractions. Even when you have some experience that can get to you. I am involved in a legacy PHP project from the early 2000s. The code is as you would expect, maybe a little bit better because the programmers involved were pretty capable, but it is code visibly evolved by first targeting PHP 4 and only then 5. For quite some time I thought that modernizing it thoroughly would be the way to go, just that it'd be too much work. Then in my day job I got confronted with a modern PHP project. Using a framework of course, written like it was Java. It was horrible. Abstractions everywhere, impossible to follow the code without getting into the details of the framework, thus very hard to make changes. That experience confirmed the decision we made with the other PHP project of only modernizing it carefully, putting the HTML in a view layer and stuff like that, but staying away from the framework trend. So this article seems spot on to me and something that can give useful input to other programmers.

arkh 6y ago
DTO everywhere and interfaces with only one implementation? And Domains. Because after reading 2 blog posts we're now doing Domain Driven Design!
- onli 6y ago
  That sounds like a different kind of pain ;) In my case it was just abstraction everywhere. Want to change one element on a site? Edit these 6 controller classes located in different subdirectories without any sense or order. Then find the template, just that there is no clear template, just PHP objects emitting HTML, JS and CSS code, so back to searching through the code. Oh, defining new functionality? Good luck finding out how to register it. It was just a ridiculously confused "MVP" pattern application for what amounted to a simple web app.
dgb23 6y ago
Sorry my comment was very imprecise: I actually agree with you and the general assessment of modern PHP (see below). What I wanted to say is that I feel like it is slightly misleading to advertise these things as bad practices if the audience is unknown. For example a beginner should probably just stick with the default idiom of a language/domain/project and understand it first, before adhering to advice given in these kinds of articles. PHP just has too many footguns so you either go with modern idioms or you are experienced enough to avoid them _safely_. Also there is the issue of documentation and learning. --- PHP is almost never my language of choice, but since I do freelance work it chooses me more often than I would like. The language is more expressive than many think and has some nice and sometimes unique useful features. But it is so inconsistent (in many ways) that your code is already ugly _before_ you start writing it (as opposed to after). That said I personally dislike writing overly abstract "OO-everywhere" programs and in my opinion PHP is _specifically_ unfit for this kind of style, since it is stateless, so everything you need to load before you do actual work, becomes a continuous performance hit (unlike for example Java, which also starts to get very fast once the JVM is warmed up). There are abstractions and utilities that absolutely make sense when dealing with PHP though: - Response & request handling with routing (parameters etc.) and middleware abstractions, including convenience for session handling and validation. - A sane abstraction over building HTTP requests (if needed). - SQL query builders (if needed) for convenience, increased safety and better error reporting. PDO is still a bit too error prone to use and is inconvenient compose. - DB migrations (if needed). - A convenient logging library. - A collection library. Built in PHP array functions are very inconsistent, straight up weird in terms of naming/functionality and incomplete in terms of what you'd expect there to be. - File handling uploads, streaming etc. (if needed). - You definitely want to use composer and auto-loading. - Probably _some_ more but you get the drift. A framework will give you all of these things (hopefully) plus a whole bunch of stuff you don't need (like ORMs, DI, code generators, template engines etc.)

by onli 6y ago

arkh 6y ago

DTO everywhere and interfaces with only one implementation? And Domains. Because after reading 2 blog posts we're now doing Domain Driven Design!

onli 6y ago
That sounds like a different kind of pain ;) In my case it was just abstraction everywhere. Want to change one element on a site? Edit these 6 controller classes located in different subdirectories without any sense or order. Then find the template, just that there is no clear template, just PHP objects emitting HTML, JS and CSS code, so back to searching through the code. Oh, defining new functionality? Good luck finding out how to register it. It was just a ridiculously confused "MVP" pattern application for what amounted to a simple web app.

dgb23 6y ago

Sorry my comment was very imprecise: I actually agree with you and the general assessment of modern PHP (see below). What I wanted to say is that I feel like it is slightly misleading to advertise these things as bad practices if the audience is unknown. For example a beginner should probably just stick with the default idiom of a language/domain/project and understand it first, before adhering to advice given in these kinds of articles. PHP just has too many footguns so you either go with modern idioms or you are experienced enough to avoid them _safely_. Also there is the issue of documentation and learning. --- PHP is almost never my language of choice, but since I do freelance work it chooses me more often than I would like. The language is more expressive than many think and has some nice and sometimes unique useful features. But it is so inconsistent (in many ways) that your code is already ugly _before_ you start writing it (as opposed to after). That said I personally dislike writing overly abstract "OO-everywhere" programs and in my opinion PHP is _specifically_ unfit for this kind of style, since it is stateless, so everything you need to load before you do actual work, becomes a continuous performance hit (unlike for example Java, which also starts to get very fast once the JVM is warmed up). There are abstractions and utilities that absolutely make sense when dealing with PHP though: - Response & request handling with routing (parameters etc.) and middleware abstractions, including convenience for session handling and validation. - A sane abstraction over building HTTP requests (if needed). - SQL query builders (if needed) for convenience, increased safety and better error reporting. PDO is still a bit too error prone to use and is inconvenient compose. - DB migrations (if needed). - A convenient logging library. - A collection library. Built in PHP array functions are very inconsistent, straight up weird in terms of naming/functionality and incomplete in terms of what you'd expect there to be. - File handling uploads, streaming etc. (if needed). - You definitely want to use composer and auto-loading. - Probably _some_ more but you get the drift. A framework will give you all of these things (hopefully) plus a whole bunch of stuff you don't need (like ORMs, DI, code generators, template engines etc.)