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

[cpradio]

@tony_marston404

@cpradio

tony_marston404:
I have already answered that in post #240

I believe you said it was implied, and therefore, it isn’t specifically stated and thus at the interpretation that one chooses to accept of said content?

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

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

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

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

In characteristic #1 which states If you have to write large volumes of code before you hand control over to the framework, then how can you say that the flow of control is dictated by the framework?

Which refers to post #238

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

Where?

Which in turn refers to post #227
http://www.sitepoint.com/community/t/would-you-agree-this-is-the-definition-of-a-php-framework/191138/227?u=cpradio

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

[TomB]

@tony_marston404

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.

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.

[tony_marston404]

@TomB

tony_marston404:
They are NOT the same. They are different languages which achieve similar results by different means.

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

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.

[TomB]

@tony_marston404

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

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

Which means they are different by your own definition. 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 because the cake has replaced the butter

[TomB]

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

[tony_marston404]

@cpradio

tony_marston404:
How so?

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.

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.

[TomB]

@tony_marston404

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?

[tony_marston404]

@TomB

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

Tony you already said they’re different here:

Uncle Bob is saying that SRP has replaced SoC because SRP now includes the ideas of Coupling and Cohesion which SoC did not. They are NOT different concepts which will produce different results.

SRP == SoC + Coupling + Cohesion

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

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.

[cpradio]

@tony_marston404

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.

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.

[cpradio]

@tony_marston404

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.

What?

So the definition of SoC does not include cohesion and coupling. K, got that.
SRP does include cohesion and coupling in it.

How are the two identical again?

[TomB]

@tony_marston404

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.

This makes zero sense at all. They’re the same but they’re different… right… If they have a different (“better”) definition they are… different… otherwise the definition would be the same and the concept would be the same.

You’re honestly saying that two things with different definitions are the same?

you should be a theologian, you’d be able to doublethink your way into solving the holy trinity problem.

[tony_marston404]

@TomB

tony_marston404:
That’s a ridiculous argument. It is simply not enough to create classes at random without considering cohesion and coupling. Good design requires the creation of classes which exhibit high cohesion and low coupling. SoC did not mention cohesion and coupling because those two terms did not exist when SoC was devised. SRP took care of that by combining those three terms into a single principle. Thus SRP is used INSTEAD OF SoC, not AS WELL AS.

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.

It proves nothing. Whether you follow a process with the label SoC or the process with the label SRP they are still the SAME process. SRP is a later version of SoC, but it is still the same concept which produces the same result.

[TomB]

@tony_marston404

It proves nothing. Whether you follow a process with the label SoC or the process with the label SRP they are still the SAME process. SRP is a later version of SoC, but it is still the same concept which produces the same result.

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

They’re the same but they’re different. So Windows 95 is the same as Windows 7 because one is a “later version” of the other, right?

[tony_marston404]

@TomB

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

I disagree. They are rules which can only be set in the Model but which are passed to the View for execution. This is SOP in the programming world, and has been for decades.

[TomB]

@tony_marston404

I disagree. They are rules which can only be set in the Model but which are passed to the View for execution. This is SOP in the programming world, and has been for decades.

[citation needed]

Nobody has ever advocated putting display logic/data in the model.

[tony_marston404]

@TomB

tony_marston404:
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.

It is NOT repeated code! The same code is run many times, but each time it produces a different result by creating new records on the database or new files on disk.

The DRY principle is only violated when you have identical blocks of code appearing in multiple places in the same piece of software.

[TomB]

@tony_marston404

It is NOT repeated code! The same code is run many times, but each time it produces a different result by creating new records on the database or new files on disk.

…which contain similar code.

[mAAdhaTTah]

@tony_marston404

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.

You are welcome to prefer your approach. You are not welcome to redefine words. Laravel, Symphony, et al are frameworks.

[tony_marston404]

@cpradio

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

Uh what?!? Where did this come back to concern and responsibility?

I was answering your point which said

I believe you said it was implied, and therefore, it isn’t specifically stated and thus at the interpretation that one chooses to accept of said content?

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?

[TomB]

Just to be clear, you have previously stated that

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

Soc (Separation of Concerns) and SRP (Single Responsibility Principle) mean exactly the same thing.

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

What a useless definition! Every programmer I know considers a “separate concern” and a “single responsibility” to mean exactly the same thing. How are they different? [quote=“s_molinari, post:399, topic:114913”] your monster class breaks both definitions. Your own description of what it does points this out. If you read Robert C. Martin’s article at http://blog.8thlight.com/uncle-bob/2014/05/01/Design-Damage.html you will see the following: My framework implements the 3 Tier Architecture…

http://www.sitepoint.com/community/t/would-you-agree-this-is-the-definition-of-a-php-framework/191138/156?u=tomb

And you’re now saying that

@tony_marston404

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.

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?