I NEVER had the “problem”. Having include/require statements is NOT the same as having a problem with include/require statements.
Remember that I developed my framework and my major application years before autoloaders were invented, so I did what was standard practice at the time and used the include_path.
Believe it or not I have not had to write a single include/require statement for many years. Why not? Because the few include statements that exist in my framework are executed by the framework code, and I never have to write any in any of the application components which I create using my framework.
I repeat, I do NOT have any sort of problem with include/require statements, so I do not need any sort of solution.
You’re backtracking and using weasel words again. You’re the one who started using the word “Problem” when you said “I do not have the problem autoloaders solve” Everyone one is only using the terminology you started with and incorrectly used. Now trying to backtrack your way out of this lie is not helping you.
Autoloaders are simply a method of loading class files, as are require_once statements. You can choose to use one method or another but they both serve exactly the same purpose. If you can use require_once to load a class you can use an autoloader.
But again this is the same misrepresentation’s game you keep playing. Stop moving the goalposts. You stated, at the start of this discussion “I do not have the problem autoloaders solve” a 100% inaccurate statement if you’re defining what they do as “solving a problem” which you apparently are.
Incorrect. All the include/require statements are taken care of in the framework code. I do not have to write a single include/require statement in any of the components which I generate using my framework.
Just to be clear: I’m not telling you to go through and change your code. I am just pointing out that you make factually inaccurate statements so you don’t have to get into discussions about alternative approaches. Which, by your resistance here you are continually proving.
All those statements are entirely wrong. For your information I have been maintaining and enhancing my framework for over 10 years, so implying that it is difficult to change is a downright lie. I have also used my framework to develop a large enterprise application which went live for its first customer in 2008, and which I have constantly maintained and enhanced since then, and still do. My business partner, an experienced software developer and project manager, likes my software because of what it can do, but also likes it because of the speed at which I can add in new modules or customisations for new clients. If my software was as bad as you make out then none of this would be possible, so stick that in your pipe and smoke it!
I disagree but I’m willing to let that slide. I have to wonder how experienced a developer your business parter is though. I’m guessing very little. It doesn’t negate the fact that you lie, don’t understand basic programming practices, argue against anyone who doesn’t code the exact way you do and have a Luddite approach to new technologies. What is the cut off point for “usefulness”? it just seems that anything that was invented (Edit: Or more accurately, you found out about) after about 2000 is somehow “bad”, “evil” or “wrong” in your eyes.
That situation neither prevents me from using an autoloader nor requires me to use an autoloader. Just to be clear, in none of the include statements which appear in my framework do I have to specify the path as that is already covered by my use of the include_path directive.
But where does it say that you can mock, deride and ridicule all the old ideas which still work? My position is that I am NOT going to change my huge existing code base to incorporate these new ideas as it would require enormous effort, at enormous cost, for no benefit that my customers would notice.
I do use dependency injection, but only in those circumstance where it is appropriate.
I do not use namespacing.
I do not use autoloaders.
I use a singleton because I have learned to use it properly and without the side effects that other developers seem to encounter.
I do not favour composition over inheritance as I do not have any complex class hierarchies in any part of my framework. Every Model class inherits from a single abstract class.
I have been using modular composition ever since my COBOIL days. There you are preaching to the converted.
I’m not sure why this is such a mental hurdle for you but nobody is asking you to change your code. I’ll repeat because you probably still don’t get it: nobody is asking you to change your code.
The problem, Tony, is that you come here saying things like “I don’t have the problem autoloaders solve”, “DI is EVIL”, generally deriding/calling “useless” any modern programming practice and consistently demonstrating that you don’t understand fundamental concepts like SRP and Encapsulation while speaking about them like you’re an authority. For visitors to sitepoint, this is at best misleading and at worst dangerous to their personal development as programmers.
The only reason your code gets mentioned is that you consistently bring it up, and you do so in a manner that implies “This is perfect code, this is how you should do things”. A great example is the “DI is EVIL” nonsense, you came along and said “DI IS EVIL HERE’S HOW I DO IT” as if your way were better. Yet, when pressed, you still never managed to explain why that statement had any weight.
A legacy codebase is not necessarily a pile of crap. It is possible to write software which is highly modular and well structured so that it can be enhanced and added to with extreme ease. I have been maintaining, enhancing and extending my framework for over 10 years, and I have been maintaining, enhancing and extending the major enterprise application which I developed using this framework for over 7 years. Not only do I maintain the existing modules but I also add in new ones to meet customer requirements. None of this would be possible if my software was as crappy as you seem to think.
You can spend enormous amounts of time trying to make your code “perfect”, or “more perfect than it was yesterday”, but eventually you will hit the point of diminishing returns. I have learned to stop before I hit that point.
I disagree with this statement but I’m not getting into the discussion as I refuse to look through your horrible 9000 line classes and untestable code any more.
I am not backtracking. I am simply using the description in the PHP which describes the “problem” for which the feature is a “solution”. My point is that if I do not have that particular problem then I don’t need that particular solution.
Look at what you wrote. They are “a” method, not “the one and only” method. I wrote my code before autoloaders existed, so I used the “other” method. There would be no benefit in changing my codebase to switch methods, so I prefer to spend my time on writing more profitable code.
What I wrote is not any sort of misrepresentation. Although there are some include statements in my framework they do not cause a problem, therefore they do not need a solution.
Do you ever read more than the first line of a post Tony? Mittineague was basically agreeing with you.
And there is also a point, where legacy code itself has diminishing returns. That is the point where you have to bite the bullet and either refactor or start out fresh.
sigh Are you really going to continue this lie? As I said before multiple times it’s this nonsensical notion that “I get the bus, therefore I don’t have the problem a car solves”. You can solve the problem with a car or the bus, but you still have to solve the problem one way or another. You can’t seem to decouple the problem from the solution. Require statements solve the same problem. If you can solve the problem with require_once you can solve it with an autoloader.
As I’ve said several times. You keep using this as a smoke screen because you don’t want to get into the discussion about “Which method is better?”. It’s not working Tony.
I have not lied. I have been maintaining, enhancing and extending my framework right to this very day. I have not changed it to use autoloaders because there would be no benefit in doing so.
And again, moving the goalposts. The post you quoted, as you know, was in reference to you saying all the require/include lines are in the framework. If you have changed the framework, you have added require/include lines where you could have chosen to use an autoloader => You have the problem an autoloader solves.
