Would you agree this is the definition of a PHP framework?

I would qualify that statement by saying Within that set of rules which I wish to follow. There are too many different interpretations of the rules out there and it is physically impossible to implement them all in a single piece of code. So I do what every sensible programmer does - I follow the rules that work in my current situation and ignore the rules that don’t.

“I’m avoiding the question”

You provided a definition which could be applied to a version of that class with all the methods stripped out. If you can take a method out of the class and the class still fulfils its responsibility then putting the method in the class violates SRP.

Your definition must clearly describe exactly what the class does. If I can remove any of the methods or variables and it can still meet that definition then the definition isn’t clear enough.

that should be my interpretation of best practices as there is no single interpretation that is universally accepted by all programmers, and there never will be.

I am not trying to redefine SRP and Soc. It was not me who brought up the idea that they mean different things (which they don’t).

No it does not as each script it creates and each record it adds to the database is unique, so how can it possibly violate the DRY principle?

No, you’re wrong again. You are the only person arguing about the definitions of these things. There is plenty of discussion about how they can be best applied but that’s another issue entirely.

Just because you’ve automated the process doesn’t mean it’s not repeated each time… you just coded something to do it for you. My point was, this repetition of each of those steps you mentions exactly that.

PHP most certainly IS an object oriented language according to the definition created by Alan Kay (who invented the term) and Bjarne Stroustrup (who designed and implemented the C++ programming language).

Way to miss the point… I was pointing out that if we’re discussing OOP Concepts the language we are using makes no difference.

They are NOT the same. They are different languages which achieve similar results by different means. Code that will work in one language will not work in the other.

You do not prove to me that they are different concepts, just the same concept described with different words.

How so?

You did not answer where it says code must be generated by the framework. And your interpretation of “inversion of control” still remains incorrect. A very small amount of code is required to be written to hand control off to the framework. It’s little more than:

$app>boot();```

All the additional code you referenced in that article is called _by_ the framework, after control has been passed to it.

Will you stop going off at a tangent and bringing in ridiculous arguments as it is doing nothing to enhance your credibility.

It’s called an analogy. It’s the exact same argument you are making applied to a different topic. You only want me to stop because it’s proving that you don’t have a clue what you’re talking about.

BINGO! This is exactly what cpradio is saying. Let’s replace PHP and Java with SRP and SOC and you get:

They are NOT the same. They are different concepts which achieve similar results by different means.

I have never claimed to be the king of PHP and I have never claimed that Radicore is the crown jewel of frameworks. All I have ever claimed is that my methods, which are different from yours, are still capable of producing functioning and marketable software, which means that YOUR methods are not the only methods with those capabilities. You do not like the idea that I can be different yet just as good.

No you haven’t. You have claimed that:

  • Inheritance does not produce coupling
  • DI is EVIL
  • Singletons don’t produce tight coupling
  • SRP is the same as SoC
  • A 9000 line class follows SRP

This is the problem tony. You spread erroneous information and you pretend to be an authority.

“Just as good” is subjective. Unless you’re going to provide a metric you’re using to measure “good”, it’s a pointless statement to make. The problem is, where you claim it is “just as good” based on known metrics, like SRP, where your code is measurably worse… so you have to start trying to redefine SRP so that you can call your code “good”.

No, we do NOT agree. SRP and SoC are NOT different concepts, they are the same concept being described using different words.

Only an unreasonable person would want me to explain what “reasonable” meant.

The fire is applying Radiant heat and Induction, well, is Induction. The way it heats the vessel containing the water to bring it to a boil greatly differs. The outcome is boiling water, sure, but the two are entirely different in their approach. Which is exactly what everyone is trying to inform you with SRP versus SoC.

Tony you already said they’re different here:

SRP == SoC + Coupling + Cohesion

Your words. Unless Coupling and Cohesion are meaningless (they’re not), then SRP != SoC by your own definition.

To say that now SRP == SoC is like saying

Cake == Butter + Flour + Eggs

Therefore Cake == Butter

It’s a weasel word ( https://en.wikipedia.org/wiki/Weasel_word ) so yes, it is important for you to explain what you mean. Such sweeping statements are meaningless: “Only an insane person would claim not to be insane”… it’s tripe.