If you look at his code, he does though. The fact that it’s not in a list and is spread around his code in various methods is irrelevant. I posted a list of excerpts from his site in #89 and that’s only a fraction of them if you look through his RADICORE framework.
They’re not in a list but that’s just because he’s not following the standard that most people did in PHP4 where they would declare all required files at the top of the current file.
A quick thought regarding the “long list of needed includes”:
The long list of includes is just a symptom of the problem an autoloader solves. Literally one (1) paragraph further down in that same php.net page, you’ll find the following:
You may define an __autoload() function which is automatically called in case you are trying to use a class/interface which hasn’t been defined yet.
This is the problem that an autoloader solves. This is a problem in every (yes every) application that has or will ever use the php keywords class or interface.
That statement is so wrong it is unbelievable. It’s like saying that if you have a problem such as a cut, and the solution to that problem is a bandage, then because I can apply a bandage at any time, even when I don’t have a cut, then I must have the problem for which a bandage is the solution. Even when I don’t have a cut, because I can apply a bandage then I must have a cut.
You’re actually trolling now. Again with the misrepresentation.You have 500+ cases where you COULD HAVE used an autoloader to solve a problem. You chose to solve it in another way, you still had the problem. How is that so hard to grasp.
As I said multiple times it’s like saying “I travel by bus therefore I don’t need to travel”. It’a backwards. Just because you are using a bus doesn’t mean you don’t have the problem (Travelling). You still have the problem. You can solve it with a bus, a car, a train, walking but you still need to solve the problem.
Just because you chose a particular method doesn’t mean you don’t have the problem.
Again with the misrepresentation… methods are in classes for one. But he meant that the methods that are triggering the autoloader/using the classes are not always used . Are you actually this dense or just trolling?
That case does not exist in my framework. My code has always specified a “require” statement just before a new class is instantiated. Remember that I wrote this code several years before autoloaders became available, so I have solved this problem in the “old fashioned” way. Just because the fashion has changed does not mean that I am going to refactor working code at a huge cost for zero benefit.
You are missing the point entirely. I could NOT have solved that problem with autoloaders because when I wrote that code autoloaders simply did not exist. There would be no benefit in retrofitting them now, so I won’t.
You are not reading what was written. The statement referred to the fact that my “monster” class contains methods that are not always used. The exact statement was “He also said that not all the various methods are always used.” Those methods exist in a single abstract class which is inherited by every Model class in my application, and unless it has escaped your attention you cannot load an abstract class with an autoloader.
If I solved the problem in a different way then I no longer had the problem, and if I no longer had the problem I had no need for another solution. How is that so hard to grasp.?
Because you had the problem. Don’t try to tell me you haven’t written a require_once line in 10 years (or even 5 years, or even 2). Your statement “I don’t use autoloaders because I don’t have the problem they solve” is wrong. You have solved the problem a different way, but in your own words you solved it, therefore you have the problem.
Just because you’re choosing to use old software still doesn’t invalidate the fact that you have the problem autoloaders solve. You just solved it a different way. You could use autoloaders to solve the problem.
The problem exists in your codebase with a solution. You have the problem autoloaders solve.
By your logic the statement “I have an autoloader therefore I don’t have the problem autoloaders solve” is also true.
OK, perhaps I’m being a bit pedantic here, but from a pure development perspective, a problem that has a resolution is no longer a problem.
Or are you saying that autoloaders provide enough benefit to warrant a (from his perspective) large scale effort to change over to using it? Is there a high enough performance increase to going in and changing JUST that? Or is it just a “it’s now a best practice, so you MUST use it?”
Best practices are great, but it’s often hard to justify a mass scale effort with no quantifiable benefit other than some reduced future maintenance when there’s payable work needing done.
But by that logic the statement “I have an autoloader therefore I don’t have the problem autoloaders solve” is also true.
And as I said, there’s no way tony hasn’t written a require_once line for a class in the last 5+ years so labelling something as “solved” and putting it to bed in software we write every day is also not really a fair statement.
I never said that it wouldn’t solve the problem. What I am saying is if a problem is resolved, I don’t see the point in finding another solution unless there’s a concrete, quantifiable benefit which justifies the effort it would take to retrofit the existing code base to use the new solution.
And unfortunately, just switching from one approach to a new approach in the middle of a code base can cause other unforseen side effects, so there needs to be a quantifiable benefit to retrofitting (note: I’m not saying there would be in this particular case, other than a potential double hit in loading, though I can’t really see that happening)
Performance wouldn’t be improved by retrofitting an autoloader but application security would be. None of those require_once statements appears to be wrapped in an appropriate is_readable(), which would allow for a graceful failure in the event that one of those files can’t be read in by the server process.
Unless there’s an appropriate error handler implementation elsewhere in radicore, the thing just falls over when it can’t require a file - potentially yielding filesystem paths to the browser. Unless all of those .inc files are outside of the web root (or the server’s set up to deliver .inc files as php), that’s a serious issue.
Even just replacing the require_once’s with a custom loader function would be a vast improvement.
function radicore_require($filename)
{
if (!is_readable($filename)) {
// fail gracefully
}
require_once $filename;
}