Are today's major frameworks capable of enterprise capable applications?

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! :smiley:

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.

I moved 2 posts to a new topic: Require lines are not duplicated code

@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.

I’d just like to point out that the original discussion was specifically targeting “Today’s major frameworks”.

I’m aware of that, but that shifted gears 100 posts ago. I’m simply trying to make this more dedicated now and pushing anything outside of that question to a new topic/discussion.

Sorry, but this is like saying, I can nail in screws with a hammer.

Except you’ll have to rewrite your constructors to get your framework to work with PHP7, as a minimum.

Scott

Trying to bring the discussion back to start.

I’ve to agree with @tony_marston404 with one thing (btw nobody disagree on this): “You have to know when to use something”. So in order to do so, we have to do write down the advantages and disadvantages so that YOU can check if on your specific case you loose more that you gain. Some of those that I could think of:

Advantages:

  • Can do what require does, only for classes (address in the disadvantage)
  • Fewer lines of code (it’s automagic)
  • It removes the requirement of explicit loading every file
  • Single point of entry of everyload of files, which:
  • You can have a better error handling
  • You can do logging
  • You can manage the location of the class based on the namespace
  • You can have security checks
  • Lazy loading

Some disadvantages:

  • Lazy loading, if you want to have a bootstrap phase
  • It only works for classes
  • Can have a performance penalty because it will react on an exception (class doesn’t exist so lets load it)

From my experience, none of the disadvantages was applicable to my apps, so I would apply autoloaders

How did you reach that conclusion? PHP allows me to solve problems in either a procedural fashion, or an object oriented fashion. It even allows me to mix paradigms in the same script. There is no rule which says that I must use OO techniques for everything, so I am not obligated to follow such a rule.

And there’s no rule which says you can’t nail in screws with a hammer so you’re not obliged to follow such a rule.

There is, however, understanding the best tool for the job.