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

I disagree. For every opinion you find expressed in books, magazines or on the internet you will find a large number of contrary and contradictory opinions, so which opinions are right? The fact that I choose to hold a different opinion to you does not make me wrong. It is a free country (at least it was the last time I looked) and I have the right to hold whatever opinion I like. I will not bow to the self-appointed paradigm police who seem to think that their opinion is the only one worth having and all dissenters are heretic who should be burnt at the stake.

Off Topic:

My understanding of the way discussion works is that each person puts their own point of view, and then considers the opinions of other participants. Unless you want to talk to yourself (in which case you don’t need a forum to do it), you should let Tony voice his own views.

1 Like

Fair enough, I was subtly trying to pre-empt tony’s inevitable avoiding the question and steer him towards a proper answer.

So that explains why TomB keeps calling me a liar just because he doesn’t like what I say, and doesn’t understand the difference between “having a problem” and “not having a problem”.

And again, a false dichotomy. The opinion of a single developer who is well behind the times and doesn’t understand several fundamental concepts is not equal to academics, book authors, people who write the languages, etc. You’re comparing apples to oranges. Not everyone’s opinion is worth the same. An expert opinion is worth more than a non-expert. A sensible question is how do we define expert which we can answer as someone with qualifications, peer reviewed publications and who can justify and back up the claims they make using empirical evidence, logic and reason.

Most importantly, an expert becomes an expert because they understand the topic at hand and allow their views to be changed when new evidence comes along. A layman will argue for their opinion in spite of evidence, an expert will base their opinion on the evidence.

I repeat, there is no single document called “best practices” which has ever been agreed upon by the community, so just because I don’t follow your version of best practices does not automatically make me a bad programmer. I follow a version of best practices that has evolved over several decades of working with numerous teams on numerous projects in several different languages. I will not change these practices unless I have a good reason to do so, and nobody in this discussion has provided anything which can remotely be called a good reason. “Personal preference” maybe, but “good reason”? In your dreams.

I have told you several times what I mean by “appropriate” and “inappropriate” yet you consistently fail to grasp such a simple concept.

“Appropriate” means using something in the circumstances for which it was designed.
“Inappropriate” is the opposite, which means using something in circumstances for which it was not designed.

I have used this terminology several times when describing the use of Dependency Injection. This concept was designed for use where a dependent object could be supplied from of choice of several sources. If you change the word “several” to “single” then the circumstances fall outside the design parameters and therefore become inappropriate.

So if my use of require_once doesn’t cause a problem, then why do you keep insisting that I stop using require_once and switch to using an autoloader? Surely that is a contradiction?.

Again you’re choosing to ignore some fundamental facts, best practices become best practices because of all the solutions to a given problem have been tried, tested, analysed and directly compared. The “Best” one is then put forward as “best practice” by the community at large. This is an awful lot of clever people who have come together to share their thoughts. Each time someone proposes a practice it is critiqued and discussed among the community, from here “best practices” emerge because they are measurably better in some way than other practices. Essentially best practices are peer reviewed by the community.

Where your arguments always fall flat is you argue against “best practices” but as soon as you’re asked for your reasoning, evidence or the metric you are using to claim your proposed alternative to the given best practice you fail to deliver and instead launch into tirades about best practices in general, false dichotomies and this very unhelpful “everyone is wrong but me!!” attitude without ever actually bringing anything that supports your claims directly. You divert attention away from the topic at hand in order to avoid direct questions like “Why is X better than Y?”

And again with the obfuscation, misdirection and weasel words. What you actually said was:

Whether or not DI is appropriate boils down to a simple question - how many alternative classes can be used to supply a dependent object. If the answer is “more than one” then DI is appropriate.

Which is unsubstantiated. You are not defining what makes it appropriate. As I said before it’s like saying:

Whether or not a unicycle is appropriate boils down to a simple question - how many passengers will there be? If the answer is “one” then a unicycle is is appropriate.

What your very poor attempt at reasoning fails to address is that DI can be used wherever an alternative can regardless of how many variants there are. In my analogy: Why should I use a unicycle instead of a car if there is only one passenger?

This is the question you cannot answer: “Why should I use an alternative instead of DI if there is only one variant?”.

You never actually explain how you’re quantifying “appropriateness”. You claim “DI is less appropriate” but not how you’re measuring that. What makes DI less appropriate that another solution if there is only one class? What makes another solution “more appropriate”. You can’t answer these kinds of questions and you make a point of avoiding them.

Complete this sentence:

“When there is only one implementation, DI is less appropriate that a singleton because…”

and

“When there is only one implementation, a sigleton is more appropriate than DI because…”

I argue against it because it would not actually “improve” my code, just make it fashionable. My customers prefer functional over fashionable, so excuse me if I place more value on their opinions than I do yours.

I should have guessed you’d take me out of context there and completely ignore the rest of my post but anyway, I’ll bite:

Require_once doesn’t cause the problem you claim to have solved (loading files(. It does cause its own problems, repeated code, no way to gracefully handle errors, inflexibility.

Your customers, much like yourself, do not understand what an autoloader is for so this statement is pointless.

1 Like

In the first place what you are suggesting is not a better alternative, just a different way of doing something that is already being done.

In the second place you are not “suggesting” anything at all. You are repeatedly telling me that if I do not follow your diktats immediately and without question then I am not following “best practices” and can be regarding as being a crap programmer, an outcast, a heretic.

How can anyone be this ignorant?

Given various metrics:

  • Performance
  • Flexibility
  • Readiblity
  • Reusability
  • Lines of code

and others, we can directly compare two or more solutions to the same problem. It’s then possible to say “By metric X, Solution Y is better than solution X”, which is where best practices come from.

For example, a simple scenario:

Given

Solution A:

$array = [1,2,3];

for ($i = 0; $i < count($array); $i++) {
	
}

Solution B

$array = [1,2,3];

$count = count($array);
for ($i = 0; $i < $count; $i++) {

}

We can accurately say “By the metric of performance, Solution B is better than solution A” which is why B is a “best practice”. You seem to see “best practices” as some sort of nebulous, incredibly subjective collection of vague coding styles. I suggest you go and do a bit of reading around the subject before making yourself look any more ignorant of the topic.

You have stated yourself in post #192 that require_once statements do not cause a problem. You said

So if it doesn’t cause a problem then why should it need a solution?

As I already said, they cause their own set of problems

  • Repeated code
  • Ungraceful error handling
  • Inflexibility
  • Code portability is heavily reduced

Firstly, you are as subtle as a bull in a china shop.
Secondly, your answers have been anything but “proper”.

I base my opinion on the evidence of my own experience which has been gained from decades of developing software in numerous teams for numerous companies on numerous projects using numerous languages. My experience has more value to me than your opinion.

Which is precisely why RADICORE has no relevance in contemporary application development. Thankfully.

1 Like

Your limited experience is nothing compared to the combined centuries of experience of everyone else, however.