I’d just like to point out that the original discussion was specifically targeting “Today’s major frameworks”.
I’m aware of that, but that shifted gears 100 posts ago. I’m simply trying to make this more dedicated now and pushing anything outside of that question to a new topic/discussion.
Sorry, but this is like saying, I can nail in screws with a hammer.
Except you’ll have to rewrite your constructors to get your framework to work with PHP7, as a minimum.
Scott
Trying to bring the discussion back to start.
I’ve to agree with @tony_marston404 with one thing (btw nobody disagree on this): “You have to know when to use something”. So in order to do so, we have to do write down the advantages and disadvantages so that YOU can check if on your specific case you loose more that you gain. Some of those that I could think of:
Advantages:
- Can do what require does, only for classes (address in the disadvantage)
- Fewer lines of code (it’s automagic)
- It removes the requirement of explicit loading every file
- Single point of entry of everyload of files, which:
- You can have a better error handling
- You can do logging
- You can manage the location of the class based on the namespace
- You can have security checks
- Lazy loading
Some disadvantages:
- Lazy loading, if you want to have a bootstrap phase
- It only works for classes
- Can have a performance penalty because it will react on an exception (class doesn’t exist so lets load it)
From my experience, none of the disadvantages was applicable to my apps, so I would apply autoloaders
How did you reach that conclusion? PHP allows me to solve problems in either a procedural fashion, or an object oriented fashion. It even allows me to mix paradigms in the same script. There is no rule which says that I must use OO techniques for everything, so I am not obligated to follow such a rule.
And there’s no rule which says you can’t nail in screws with a hammer so you’re not obliged to follow such a rule.
There is, however, understanding the best tool for the job.
This is your whole problem Tony. You have a screw and want it “inserted” (a large application) so you pick a hammer to do it (procedural code mixed with OOP), whereas a proper screwdriver or even a cordless screwdriver, maybe with some pre-drilling of the hole (full OOP), would be a much better solution.
I don’t expect you to understand why that is, because you have proved time and again, that you don’t understand what a full OOP application is or what it should be.
What I find disappointing is you don’t admit it either.
At least you know you don’t do OOP “completely”. I just wish I could replace “completely” with “as it should be” in that sentence and not have to fight you with your “but I do it this/my way” all the time. Your way is simply wrong. It might work and it might have semblances of proper programming from a decade ago, but today, “your way” is just simply wrong much less advantageous than using OOP the way it was meant to be used.
Scott
1 Like
Let’s not use the word “wrong” as it’s very ambiguous. What we really mean is “has significant disadvantages compared to other methods” we’ve highlighted some of those in both threads: inflexible, hard to test, hard to understand, etc.
2 Likes
So I agree with everyone. In fact, I find it a bit appalling that PHP let’s you mix the two styles, but that isn’t likely by choice but rather how difficult it would be to do that detection and force you one way or another (not to mention the performance hit of such a check).
If you look at other languages, they make it pretty difficult to write in a procedural manner. So yes, this is very much like nailing a screw with a hammer, but welcome to PHP where you are also more than welcome to shoot yourself in the foot.
There will always be people who will do it, many by accident, some because they don’t know any better, and others make it an actual choice. Whatever the reason, there isn’t much we can do other than point out alternatives that would solve their problem the exact same way and show any intangible benefits (think TDD, mocking, maintainability, SRP, etc). There are ways to have those measure tangible benefits, but that’s another discussion altogether.
Agreed. Thanks for the correction. I’ve corrected my post. Is that better?
Scott
2 Likes
This is a ridiculous argument. There is no rule that says that I shouldn’t eat peas with a knife, or eat soup with a fork, or cut my nails with a chainsaw, but that does not mean that I can, or even try. Anybody with an ounce of common sense should be able to see that.
I was paraphrasing you! Did you even read the post you quoted?
You’re the one saying “I can eat peas with a knife” here.
It may be a large application, but it has been broken down into separate modules each with their own assigned responsibilities. There is no proof that “full OOP” instead of “partial OOP” would produce any real benefits. The only thing it is guaranteed to produce is more code to do the same thing, and as a minimalist I prefer to choose the “less code” option.
Where is there any proof that a “full OOP” solution is better than a “partial OOP” solution?
The only thing I will admit to is only using OOP in those places where it can demonstrate that it has distinct benefits.
The rules of proper programming do not change that often. H. Abelson and G. Sussman wrote the following in their book “The Structure and Interpretation of Computer Programs”:
Does the fact that these words were written way back in 1984 mean that they are no longer valid? I think not.
Do not attempt to tell me how OOP was meant to be used as you are baring up the wrong tree. Like any paradigm in any language it provides certain features - encapsulation, inheritance and polymorphism - and it is entirely up to me how I use those features in order to produce the best results. For me (and my customers) it is results that count, not the technique which I used to produce them.
Post edited by cpradio to remove unnecessary baiting/semi-personal attacks
I would put this as “perceived to have significant disadvantages”, but as your perception is blinded by dogma you do not see what is there, only what you think is supposed to be there.
[citation needed]. We’ve already covered these disadvantages dozens of times so I’m not going into them again in detail but just quickly. Difficulty to test, inflexiblity, hard to reuse in other projects, difficult for someone else to understand. These are in no way “dogmatic” they’re entirely pragmatic. Having code which is hard to test is a disadvantage compared to code which is easy to test. Whichever way you want to look at it, there’s nothing “dogmatic” or even perceived about that, it’s entirely quantifiable in time spent testing the code.
I could, but I won’t, for the reasons which I have stated.
What does this even mean? This bears no relation to the original post. This is yet more tony marston sidestepping the issue. You’re the one who initially said
Which is the “peas with a knife” analogy. Mixing OOP and procedural code is exactly that: Using the wrong tool for the job. I don’t know what point you’re trying to make here and neither do you, you’re just trying to sidestep the issue.
This single sentence is incredibly telling of your underlying misunderstanding about best practices, modern techniques and programming in general. The underlying techniques have a direct impact on the end result in terms of production time and quality. Best practices and modern techniques (Such as unit testing in particular!) allow you to get those results much more quickly by fully utilising all the tools at your disposal. Ignoring certain techniques and tools (Autoloaders, OOP, Namespaces, Unit testing, to name just a few of the things you don’t like) will have a direct impact on the end result. It will take longer to build, it will contain more bugs because it’s not as thoroughly tested and it will be difficult to reuse components in another project, meaning that future projects also take longer due to duplication of effort.
Post edited by cpradio to remove the personalization (just the last sentence)
1 Like
Stop saying this please. Your 9000 line class makes such statements null and void and we’ve clearly pointed out that you don’t understand SRP, as it should be understood.
A pretty clear indication is the the fact that pretty much all teachings of OOP languages, at least the ones I’ve come across, teach OOP (there really is no such thing as “full OOP”). They don’t say “oh, you can mix procedural and OOP with this language too and it is just as good” and also show students such alternatives. They don’t do it, because mixing procedural code and OOP is most definitely NOT as good as just OOP alone, especially for medium to large projects. I won’t argue with the quick PHP script here or there, that it might be faster to throw together with some procedural code to get it done. We are discussing about “enterprise capable applications” here, so OOP is the way to go.
Corrected. And we are trying to show you that what you think needs reassessment. And I still think it is disappointing you won’t admit to that. That is the core issue here.
Actually, I agree with you here and I misworded my reply. The styles and practices of using a language to program is what changes, because the language itself changes/ improves over time. That is what I meant. And your programming style resembles, partially, a style that was predominant over 10 years ago, due to the language and how it was used at the time.
PHP has evolved considerably since then and so has programming with it. It is this evolution, which seems to me, you have decided to completely ignore and that is perfectly fine. But, please don’t say you are at all “right” by doing so or go so far as to condemn those who don’t “hang back with Tony”, which you do clearly, in your “Dependency Injection is Evil” article. Staying behind the times and expecting others to accept it as “just as right” is what you are trying to achieve, isn’t it Tony?
Evolution is always a process towards perfection to meet the conditions of the surrounding environment. And more important to note is not the reaching of that perfection, which is impossible, but more the fact that there is constant improvement with evolution. You are basically ignoring the improvements made through the PHP evolution and someone who ignores those improvements is fine in doing so. It is just that they shouldn’t expect anyone else to do the same. When they do, they are simply being a wrinkle in the never ending evolutionary rug, which some people, unfortunately, end up tripping over.
Scott
1 Like
This is spot on. He cant back up his points with anything tangible and all his arguments rest on “My code already does X without Y therefore Y is bad”. His refusal to even look into the difference between various methodologies shows his poor attitude to change.
What Tony doesn’t seem to grasp is why programming evolves. With hundreds of thousands of programmers of various skill levels working every day, pretty much every possible solution to a given problem gets tried eventually. Sometimes people will look at a solution, or a development methodology and say “Wouldn’t it be better if…?” it’s at this point new ideas such as OOP, unit testing, TDD, separation of concerns are born. Sometimes they just require re-structuring the code, other times they require a fundamental change to the language being used. Of course this is an incremental process, without classes and objects nobody would have ever thought “What if I instantiated a version of the dependency with a known state to make testing easier?” and without that, the next person wouldn’t have said “What if I wrote a script to test my class that I can just re-run every time I make a change?”. Each of these small steps are building blocks for whatever comes next.
As much as Tony wants to pretend that “The rules of proper programming do not change that often.”, it’s simply not true, they just don’t change enough that it’s obvious. There is no point where you say “That boy turned into an old man”, it’s a gradual change that we simply do not notice. These changes happen very gradually, in small incremental steps, but saying they don’t happen is factually wrong. Sometimes trends appear and then die out (Singletons being a prime example) but this is all part of the evolutionary process, those useful patterns carry on, those not-so-useful ones die out.
Posted edited by cpradio to remove a slightly personal remark
1 Like