Oh boy, did we need some comic relief here or what! LOL!
Oh boy, did we need some comic relief here or what! LOL!
I’ve been trying hard to get a plugin here called ReplyGif, it would add a button in the composer to let you choose an animated gif that best fits what you want to say
One day, this will become a reality!
I’ll drink to that!
@tony_marston404 - I didn’t indicate that you should refactor your application framework to take advantage of autoloading. I specifically wanted to show that the problem an autoloader solves is not the fact that there exists a “long list of includes”. The existence of an
require statement in a script doesn’t prevent a developer from effectively using an autoloader.
In response to a comment I made on a separate thread, you said this:
I think the rest of this community has decided that there is no point in trying to convince you that modern programming practices are beneficial, so personally, I will not do that anymore.
What I will do, however, is ask you to respect the intended audience for these forums. If you take a look at the About Us page for SitePoint, you’ll find this as the mission statement:
our mission is to deliver new ideas, emerging concepts, and teach state-of-the-art technology to our readers
You have used certain techniques to solve the issues being discussed. However, a visitor to SitePoint (e.g. those interested in new ideas, emerging concepts and state-of-the-art technology), is not the audience to whom the merits of these techniques should be discussed.
Whether or not your framework can be deployed as a viable enterprise solution is not at question here. You’ve been able to do this successfully for a decade, so that is not in question. This does not mean that modern programming techniques are not beneficial or that there are not opportunities in your code base to apply these techniques.
For the record, the state-of-the-art in PHP programming includes things like:
Of course this list is not exhaustive, but over the course of the last few weeks I’ve witness you argue against all of these items. My concern with this is that a visitor to SitePoint who is interested in staying up to date on programming concepts (e.g. those interested in new ideas, emerging concepts and state-of-the-art technology) will receive mixed messages regarding what’s acceptable and how a concept should be employed.
I imagine you’ll want to argue about how the modern practices are un-necessary and don’t offer valid benefits because you’ve been able to solve the same problems your own way. Again, this is not a commentary on your framework or how you have solved a problem in the past. It would be best though, to focus on how to employ new ideas, emerging concepts and state-of-the-art technology.
If you’d like to continue the discussion that has been had thus far, perhaps you could spin up a forum on your own website where it could continue.
I think a big problem with this discussion is that it’s possible to go round and round debating about what certain terms and concepts mean or how they should be implemented… it’s too theoretical. One of the core arguments that Tony seems to make is that it doesn’t make good business sense to implement newer language features or implement what some consider ‘best practices’, as they would bring no advantages.
What would be ideal would be a way to assess the practical application of the approaches advocated by each side. It would be interesting to take a specification for a small application and have Tony and Tom / Scott build it using their chosen practices and then compare the time taken (and perhaps some other metrics). Then, the next step would be to introduce a change in the requirements and see which ‘team’ can implement those changes in the least time. I know it’s not likely to happen, but I think it would help to show whose methodology/programming practices provide demonstrable, practical benefits.
I tend to be more an idealist than a pragmatist. i.e. I want my code to be “perfect”.
But the reality is there aren’t enough hours in a day and I won’t live enough lifetimes to do everything I’d like to do let alone go back to fixing up my older code.
As much as I cringe when I see members here say something like “but my FrontPage / DreamWeaver code works” there is something to be said about something “working” as horrid as it might be to some.
As I said, there comes a time with aged code that it will need to either be abandoned, rewritten, or patched.
Life is only so long, more so if you are working under a deadline, and sometimes one has to compromise “would be nice to have” with “good enough”
Not to mention in the real-world it is difficult to quantify the value of large refactoring efforts unless there is also some type of functional or visual update associated with it. You can’t just say to most suites you are going to spend 3 months time refactoring/rebuilding something but nothing will change but underlaying code. It just isn’t realistic or cost effective unless of course it is done in parallel with solving specific business problems that can be quantified.
This topic (and others) probably would have gone better if we had distinguished between new and legacy applications. Whether it’s a good idea to use X when starting from scratch is a very different question than whether it’s worth the effort to refactor X into an existing codebase.
Of course an extension to that is the question “should you use a legacy codebase on a new project?”
Getting back on topic. Has anyone worked with a framework to build an enterprise/ LOB application, other than Tony? If yes and possible, can you explain a bit about the application and what framework was used?
You do not understand simple logic, do you? Having something and having a problem with something are entirely different situations. I do not have a problem with writing include/require statements, so I do not need any sort of solution to help with that writing of include/require statements.
Thank you for adding a sensible comment to this discussion, one based on common sense instead of unadulterated dogma.
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.
I agree 100% with that statement.
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.
That is not what he wrote. I can only comment on what he actually wrote and not something that was in his head at the time he wrote it.
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.
And you haven’t changed your framework in 10 years? A simple look at your site http://www.radicore.org/archive.php?article_type_id=NE proves that statement wrong. More lies…
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!