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

If you bothered reading the other posts in this discussion you will se plenty of places where inferences are made all over the place such as “the article switches between using concern and responsibility, but as it does not expressly say that they are the same I can only conclude that they are different”.

Which further proves my point. If SRP is used instead of SoC then they are different concepts otherwise nothing would have needed to be replaced and we’d still be using SoC.

By your own definition they are different, have different meanings and are applied in different ways.

SRP took care of that by combining those three terms into a single principle.

And if SoC and SRP were the same, this would not have been necessary in the first place because we’d already be using SRP, just calling it SoC.

Tony Marston: “I combined a banana an apple and a pear. Some people call it a fruit salad but I call it a banana”

Honestly tony the logic here is ridiculous: Combine 3 things together and it’s identical to one of the original things. This is some sort of homeopathic programming (and we all know how well that works)

It is not wrong, it is different. I am not stretching the definition, I am sticking within the bounds of what it actually says and not going beyond that. I am applying a reasonable and moderate interpretation. It is YOU who are trying to take it to extremes.

I disagree. Those are merely pieces of data which are passed to the View object at runtime in order to alter what the View object actually does. It is a rule which is set within the Model class but passed to the View object in order to be executed.

And if you need different information about the CSV e.g. maybe you want to pivot the table 90 degrees, you need another variable in the model. +1 reason to change.

These are display variables and belong in the view. Broken SRP, broken SoC. Well done.

I disagree. If you construct more classes to achieve a result then you have to instantiate and pass control to more objects to achieve that result. Coupling is directly related to number of method calls, so the more calls you have the more coupling you have.

I disagree. Methods in the same class are not coupled as there is no call from one object to another. Methods in the same class contribute to cohesion, not coupling.

According to your logic if I use the “Add Customer” transaction 100 times to add 100 different customers to my database then I have violated the DRY principle simply because I have used the same transaction 100 times. Do you now how ridiculous that sounds?

If it’s generating similar code 100 times then yes, it is violating DRY. Just because you automated the repetition and didn’t have to type it out repeatedly doesn’t mean there isn’t repeated code, it’s just automatically generated repeated code.

You are seriously missing the point. This is a PHP group, so all the code samples should be for PHP as those who don’t use the other language will not have the faintest idea what you are talking about… It’s called common sense, dude.

If you don’t have the faintest idea what a TextField and Button are you don’t belong in any discussion about programming. I didn’t supply any code… just class names. Pretend it’s PHP if you like.

I disagree with “is required to be written by hand” as although it is required, with the Radicore framework it is generated and not written by hand.

Incorrect. I simply refuse to waste time by disproving your analogy. Please stick to the ACTUAL topic and don’t switch the discussion to something else entirely.

Uh what?!? Where did this come back to concern and responsibility? It was in regards to the lack of code needing to be written being implied… I suggest you actually read the posts Tony, I did :smile:

Here is Post #240 for reference, it has nothing to do with concern or responsibility.

Which refers to post #238

Which in turn refers to post #227

Thanks, but I did my due diligence and read post 240 before responding :wink:

So you don’t know what an analogy is then. I suggest you look it up, it’s not “switching the discussion” it’s pointing out your logic is flawed by applying the same logic to another use-case. I don’t want to talk about bananas or cakes, I’m not switching the discussion only highlighting the flaws in your argument. I can see why you don’t like me doing this though.

What ARE you talking about? The known differences between two languages such as PHP and Java are totally unrelated to the theoretical differences between two concepts which use different words to express the same meaning.

By your own definition they dont. Please stop arguing this, you’ve lost

Please answer this tony: How can combining 3 different things together result in something identical to one of those 3 things?

Your analogy is flawed, Either technique can be used to heat water but you only ever use one of them, never both. They are simply different ways to heat water.

It is the same with SRP and SoC. You either use one of them or the other to create modular software, but never both. SRP is the same as SoC but more modern as it incorporates the notions of cohesion and coupling which did not exist when SoC was first described.

Please answer this tony: How can combining 3 different things together result in something identical to one of those 3 things?

You either use one of them or the other to create modular software, but never both.

I don’t know what’s going on in your head now.

  1. You’re adamant that SRP and SoC are “the same thing with different names”

  2. Now you’re saying “You can apply one but not both”… if they were “the same” applying one would by definition apply the other

So which is it? Are they the same or not?

Incorrect. I am saying that SRP redefines SoC by including references to cohesion and coupling. It is a better definition of the same concept, not a definition of a different concept.

No, I’m fairly certain I can come up with a few reasons why I’d want to use both in an experiment/application. The way heat is applied can affect the outcome, ask any Chemist out there.