5 ms·

You're probably a bit too hard on the emerging techniques - Class loading is easily one of the best things to happen to PHP in years (along side closures). But

You're probably a bit too hard on the emerging techniques - Class loading is easily one of the best things to happen to PHP in years (along side closures). But... I'm inclined to agree with you about OO. It's far over used by developers who don't have the experience to know when to stop. Dependancy Injection? God damn, are we actually solving problems or covering up issues with a programming paradigm? This solves a problem I never knew I had... Traits and "mix ins" blow my mind. How bout just using a bloody function call in a library (yes, these can be testable just fine too without the word "class" in there). Maybe I've just head my head neck deep in functional/procedural code for too long to appreciate things, but none of my OO systems has ever achieved the need for overly complicated management systems like DI or traits.

deleted 14y ago
[deleted]
jbwyme 14y ago
There is certainly a line that can be crossed when it comes to over thinking OO. However, Dependency Injection enables you to write much more testable code where in many cases people would use static methods therefore breaking the ability to properly unit test. As for your argument against traits, using global functions clutters up the global namespace and doesn't lend very well to modular development. Next thing you know you have two libraries with "create_hash($string)" or something similar that do two different things. *Edit: clarification
- contingencies 14y ago
  (1) Though I am not familiar with the subject (I avoid OO PHP), you seem to raise a valid point; however one could also consider that the same could probably be achieved with less lines of code, arguably looser coupling, greater re-usability and increased conceptual clarity by not writing that code within an OO model at all. (2) The namespace argument is a valid one; however; in what percentage of deployment environments is such a concern truly likely to come to the fore? Usually very few, and when combined with non-braindead naming conventions (eg. 'mylibrary_function()') basically never.
  - wvenable 14y ago
    > one could also consider that the same could probably be achieved with less lines of code, arguably looser coupling, greater re-usability and increased conceptual clarity by not writing that code within an OO model at all. OO is all about loose coupling, greater re-usability, and conceptual clarity. That is literally the point of it all. You can fume about the abuse of OO but the exception is not the rule. It's quite unlikely that, in general, plain old procedural code is better for coupling, re-usability, or clarity unless your problems are boringly simple.
    - contingencies 14y ago
      > OO is all about loose coupling It's theoretically an interesting language pattern. However, it grew from controlled environment of experiments for which it is most suited. It's perhaps telling that, today, a fairly large number of experienced programmers tend to avoid it. Have a look at the interviews in 'Coders at Work: Reflections on the Craft of Programming' for some good examples. I actually just bought this book again specifically to find this quote, which is gold: "Armstrong: I think the lack of reusability comes in object-oriented languages, not in functional languages. Because the problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. If you have referentially transparent code, if you have pure functions-all the data comes in its input arguments and everything goes out and leaves no state behind-it's incredibly reusable. You can just reuse it here, there, and everywhere. When you want to use it in a different project, you just cut and paste this code into your new project. Programmers have been conned into using all these different programming languages and they've been conned into not using easy ways to connect programs together. The Unix pipe mechanism-A pipe B pipe C-is trivially easy to connect things together. Is that how programmers connect things together? No. They use APIs and they link them into the same memory space, which is appallingly difficult and isn't cross-language. If the language is in the same family it's OK-if they're imperative languages, that's fine. But suppose one is Prolog and the other is C. They have a completely different view of the world, how you handle memory. So you can't just link them together like that. You can't reuse things. There must be big commercial interests for whom it is very desirable that stuff won't work together. It creates thousands of jobs for consultants. And thousands of tools to solve problems that shouldn't exist. Problems that were solved years ago." Peter Seibel. Coders at Work: Reflections on the Craft of Programming (Kindle Locations 2680-2689). Kindle Edition.

deleted 14y ago

[deleted]

jbwyme 14y ago

There is certainly a line that can be crossed when it comes to over thinking OO. However, Dependency Injection enables you to write much more testable code where in many cases people would use static methods therefore breaking the ability to properly unit test. As for your argument against traits, using global functions clutters up the global namespace and doesn't lend very well to modular development. Next thing you know you have two libraries with "create_hash($string)" or something similar that do two different things. *Edit: clarification

contingencies 14y ago
(1) Though I am not familiar with the subject (I avoid OO PHP), you seem to raise a valid point; however one could also consider that the same could probably be achieved with less lines of code, arguably looser coupling, greater re-usability and increased conceptual clarity by not writing that code within an OO model at all. (2) The namespace argument is a valid one; however; in what percentage of deployment environments is such a concern truly likely to come to the fore? Usually very few, and when combined with non-braindead naming conventions (eg. 'mylibrary_function()') basically never.
- wvenable 14y ago
  > one could also consider that the same could probably be achieved with less lines of code, arguably looser coupling, greater re-usability and increased conceptual clarity by not writing that code within an OO model at all. OO is all about loose coupling, greater re-usability, and conceptual clarity. That is literally the point of it all. You can fume about the abuse of OO but the exception is not the rule. It's quite unlikely that, in general, plain old procedural code is better for coupling, re-usability, or clarity unless your problems are boringly simple.
  - contingencies 14y ago
    > OO is all about loose coupling It's theoretically an interesting language pattern. However, it grew from controlled environment of experiments for which it is most suited. It's perhaps telling that, today, a fairly large number of experienced programmers tend to avoid it. Have a look at the interviews in 'Coders at Work: Reflections on the Craft of Programming' for some good examples. I actually just bought this book again specifically to find this quote, which is gold: "Armstrong: I think the lack of reusability comes in object-oriented languages, not in functional languages. Because the problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. If you have referentially transparent code, if you have pure functions-all the data comes in its input arguments and everything goes out and leaves no state behind-it's incredibly reusable. You can just reuse it here, there, and everywhere. When you want to use it in a different project, you just cut and paste this code into your new project. Programmers have been conned into using all these different programming languages and they've been conned into not using easy ways to connect programs together. The Unix pipe mechanism-A pipe B pipe C-is trivially easy to connect things together. Is that how programmers connect things together? No. They use APIs and they link them into the same memory space, which is appallingly difficult and isn't cross-language. If the language is in the same family it's OK-if they're imperative languages, that's fine. But suppose one is Prolog and the other is C. They have a completely different view of the world, how you handle memory. So you can't just link them together like that. You can't reuse things. There must be big commercial interests for whom it is very desirable that stuff won't work together. It creates thousands of jobs for consultants. And thousands of tools to solve problems that shouldn't exist. Problems that were solved years ago." Peter Seibel. Coders at Work: Reflections on the Craft of Programming (Kindle Locations 2680-2689). Kindle Edition.