Saying something in an external article is not the same as saying it in this discussion.
Then you haven’t been reading what I have been continuously writing. I have never said that a singleton is better than DI, but in those situations where DI is not appropriate or overkill then a more simpler method would be more appropriate. It just so happens that in my framework where I do not use DI I use a singleton. I could use a factory pattern, or a service locator, but I choose to use a singleton instead.
Yes you are. Every time I mention the places in my code where I choose not to use DI you keep telling me that I should. I agree that I could use DI, but for reasons which I have explained multiple times I choose not to. The choice is mine, not yours, so stop telling me what I should or should do.
My business partner would heartily disagree with that statement.
and your reasoning for that is…?
You’re back to “more appropriate”. Once again you’re ignoring the fact that DI is less code. lower execution time, easier to implement and overall less complex which I’ve pointed out dozens or more times and you continually ignore. See this post: Dependency Injection Breaks Encapsulation - #294 by TomB
You keep using this “complexity” argument as your measure for appropriateness but DI is LESS COMPLEX. Can’t you see this is why your argument simply does not work?
Yes you are. Every time I mention the places in my code where I choose not to use DI you keep telling me that I should. I agree that I could use DI, but for reasons which I have explained multiple times I choose not to. The choice is mine, not yours, so stop telling me what I should or should do.
Wrong. We’re asking you why you choose to use an alternative and what your reasoning for doing so is then pointing out that reasoning is flawed.
You may have those problems in your code, but they do not exist in mine.
Annnnnd we’re back to “I don’t have the problem X solves”. This argument is again, untrue and fails to recognise the underlying problem. Simply put you do. You have repeated code. Every time you use a class you must prefix it with the require once line. Just looking at your code shows you do have this problem with repeated code: http://pastebin.com/31sHHv75 so stop lying. require_once 'std.table.class.inc'; is repeated 49 times, for instance.
Nope, they do not disagree. If you read RavenVelvet’s message carefully, he was referring to ‘contemporary application development’. Your business partners are not building modern applications, they are creating or maintaining legacy applications. Because Radicore is a legacy framework, it suits well in their legacy applications. You can say that Radicore is relevant in legacy application development/maintenance, but it doesnt mean Radicore has any relevance in contemporary application development. I mean, contemporary.
1 Like
So friggin’ what? Just because I have lots of require_once statements in my application does not mean that I have a problem writing those statements. For your information all of those statements are generated by the framework and not written by the developer.
In the second place all that code was written years before autoloaders existed, so I solved the problem of locating each file in the old fashioned way by using the include_path directive. If I have already solved the problem, then I no longer have a problem which requires a solution, and there would be absolutely no benefit in changing my huge codebase to implement a different solution just because it is “fashionable”.
I can’t remember if it was this topic or another one, but I and several others agreed with you on this point, Tony, that sometimes the effort to refactor an existing application doesn’t seem to be worth the payoff. It can be especially hard to justify to bosses or clients that we would be spending time, changing a bunch of code, and in the end the application would outwardly look and work no differently.
So, for the purpose of comparing implementation choices, I suggest to everyone in this topic that we do so in the context of a brand new application. That is, if we were to sit down and write a brand new application, would we start off using require statements or an autoloader? Why or why not?
5 Likes
So repeated code is perfectly fine, right.
This is a point we’ve tried to explain to tony on numerous occasions yet somehow he brings everything back to whether or not it’s implemented in his code or not.
Yes, I’ve just looked deeper into the Radicore framework and must say, the two images above don’t even come close to express the right feeling I get when looking at the code. Sorry Tony for that. The code is not truly object oriented. It is more like a nightmare hybrid of procedural code mixed in with some really bad classes. I’ll give you a compliment though Tony. The fact it actually works is amazing.
Tony, I’d like to humbly request let’s not talk any more about your framework here please. It is a polite request for my topic. If you’d like, start a new thread to ask the great people here to discuss the merits and issues with your framework, then please do so. I bet it would be a very interesting thread too.
I’d like to come back once more to my topic, which is, do you or have you worked on an enterprise application and used a major PHP framework to help get it done?
Or as suggested, discuss architecture, design patterns or methods useful for enterprise applications in today’s PHP world.
For instance and at a lot higher level, Tom started an interesting thread on making an application server out of PHP, so that the costly part of most applications, the bootstrapping/ initialization part and also the constant rebuilding of some objects, can be avoided with each server request.
Leaders of the PHP industry, like Fabien Potencier, also agree this is PHP’s next great challenge for it to become much more widely accepted at enterprise level.
Do you agree with that? Have you worked on any bigger project, which could have definitely gained in potential, had you been able to speed up PHP this way? Or is PHP “fine” as it is?
I actually did another poll in the PHP usergroup about adding a JIT compiler to PHP to make it even more performant. It doesn’t seem like people think PHP needs it. And from what I’ve read, PHP7 is going to bring a lot of performance to the table as it is, without a JIT compiler.
I think we can look forward to nice times ahead with PHP! 
Scott
That question is not relevant to me simply because I do not write brand new applications from scratch, instead I add new modules to my existing enterprise application which uses my tried-and-tested framework.
@tony_marston404, you are more than welcome to leave the discussion if you can’t provide any additional value. The shift has been made, we are now focusing on a brand new application from scratch and whether there is any use in utilizing an autoloader over require statements.
1 Like
Are you saying that, at this point in your career, you will never write a new application that isn’t based on your existing code-base?
@TomB You’re allowing yourself to be dragged back into same argument… if you don’t bite, Tony’s got nothing to respond to and will be forced to change the subject or leave the discussion. If you keep engaging him, you’re just going to keep going round in circles ad infinitum.
[quote=“s_molinari, post:258, topic:114913”]
The code is not truly object oriented. It is more like a nightmare hybrid of procedural code mixed in with some really bad classes.[/quote]
PHP is a multi-paradigm language, so I am not forced to write code that is 100% object oriented. I use procedural code where I choose to, and I use OO only when there are benefits.
It may be amazing to you, but it’s all in a day’s work to me.
Yes and yes. Although the answer to the second question is limited to the RADICORE framework as none of the other offerings out there come close to providing what RADICORE does.
Then I am way ahead of you by having already written and deployed an enterprise application. I look forward to the improvements that PHP7 is supposed to deliver.
I moved a post to a new topic: Are there advantages to writing an application from scratch if you already have a successful product?
This is the current discussion of this topic. Please contribute to this discussion keeping in mind we are talking from a brand new application perspective. Anything off-topic will be either moved to a new discussion or removed.