…which contain similar code.
You are welcome to prefer your approach. You are not welcome to redefine words. Laravel, Symphony, et al are frameworks.
I was answering your point which said
Anything which is not specifically stated can be implied, and different people can interpret what has actually been stated in different ways with the result that they produce different implications.
My reference to “responsibility” and “concern” was to point out that as that article switched between the two terms without explicitly saying that they were different that it led me to believe that they had the same meaning. Others is this discussion came to a different conclusion - because the article did not explicitly say that they were the same they deduced that they were different.
Do you see the different interpretations of the same text? Whose interpretation would you say is the most reasonable?
Just to be clear, you have previously stated that
And you’re now saying that
SoC and SRP have different definitions (if it’s been redefined, the definition has changed)
If they have two different definitions how can they mean EXACTLY the same thing?
What are you taking about?
You are saying that SRP is SoC + Coupling + Cohesion:
How can combining SoC, Coupling and Cohesion result in SoC?
Your argument is:
SoC + Coupling + Cohesion == SRP
SRP == SoC
SoC + Coupling + Cohesion == SoC
How is this possible unless coupling and cohesion have no meaning?
Programmer A might think he’s applying SoC while programmer B thinks he’s applying SRP but the results are the identical. Same concept, same result, different wording.
And now you’re backtracking. You clearly said “You can apply one but not both”. Stop trying to weasel your way out, you’ve lost, admit it and give up.
In your own words you have stated they are not the same thing.
The fact that a scientist may try that as an academic experiment is irrelevant. Nobody in the real world would do that. For the same reason no programmer would apply SRP to achieve one set of results and then apply SRP to achieve a different set of results.
They both describe how to take a piece of software and break it down into smaller units, with the smallest being a class. They both say that separating out the logic for the GUI, business rules and database access should be the outcome of the exercise. In that respect they represent the same concept, the only difference being that they describe it using different words.
Ah, that better explains your prior response. Thanks. I didn’t read your prior response as that (ah interpretations received differently – see what I did there; see it? see it? ).
Yes, just as a “horseless carriage” and a “motor car” are different ways to describe the same concept. Do you like that analogy?
But they have the same definition. You have said that:
SoC does not include Coupling or Cohesion
SRP includes coupling and cohesion
SRP is a redefiniiton of SoC (they have different definitions)… but somehow they are the same thing… in fact you’ve said “mean exactly the same thing”. You’ve contradicted yourself somewhere!
They are the same in that they are both operating systems. Modern computers come with the latest version as all earlier versions have been superseded just as SoC has been superseded by SRP. They are different versions of the same concept, not different concepts.
So you’ll agree that these posts:
Are utter nonsense?
Is SRP “EXACTLY THE SAME THING” as SoC or not?
And the follow statements by your logic are also true: All programming languages are the same because they are the same concept, all cars are the same because they’re the same concept, all computers are the same because they are the same concept.
You misunderstood me, they do, and they do it today. Engineers are beginning to use induction heating to spot place a weld and then radiant heating to put it fully in place. The induction heating allows the parts to be set temporarily until they can be put together entirely. Thus both processes used to result to a single outcome, two pieces of metal pieced together (both of which produce that out come on their own too).
Therefore, it is reasonable to say the same could be true for programming principles/concepts.
I do not put display logic it the Model, it is all in the View. However, it is perfectly acceptable to have data in the Model, even meta-data, which is then passed to the View for processing.
“Is this page a CSV or a HTML page” is display logic, not data and belongs in the view. Interesting that you omitted my  because you couldn’t provide a reference despite calling it SOP.
Similar maybe, but NOT identical. Besides “adding new records to the database” is not the same as “generating similar code”.
If each time I run the same piece of code to generate new records in the database, how does the act of running the code violate the DRY principle?
You need to repeat the process each time. This is by definition repeating yourself.