Thank you! That’s exactly what I was asking for - that’s a quantifiable, definable benefit to justify at least considering the effort required to change over to this approach…
Just to be clear I wasn’t suggesting tony change his existing code my objection was at Tony saying “I don’t use autoloaders because I don’t have the problem they solve.”
Had he correctly stated “I don’t use autoloaders because my code is poorly organised, difficult to change without breaking things and i dont want to go rooting around in 9000 line files so I don’t want to mess with it” I wouldn’t have argued with his premise.
Oohhh…now you have me sitting on the very edge of my seat … Where is a popcorn icon, when you need one? Well I found these. Lollipopcorn. LOL!
You go always go with this image instead
@cpradio Do you even Internet? This is the standard popcorn image
Can’t see it Proxy is blocking it… waiting for the auto-download feature in Discourse to kick in and load it via a relative path… come on Discourse!!
Seems there are a lot to choose from:
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:
- Dependency Injection
- Not implementing a
- Favoring composition over inheritance
- Modular composition
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.