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

[tony_marston404]

@TomB

If you had any idea what coupling was you’d easily be able to understand why inheritance creates tight coupling.

Coupling only exists when one module calls another, not when one class inherits from another.

[fretburner]

@tony_marston404

Coupling only exists when one module calls another, not when one class inherits from another.

Could you give a brief description of your understanding of what coupling means?

[TomB]

@tony_marston404

Coupling only exists when one module calls another, not when one class inherits from another.

What exactly do you think happens during $this->method() when method is supplied by a parent/child class?

And please answer the damn question:

Is Uncle Bob wrong or are you?

Tony Marston:

it is quite wrong to say that inheritance automatically produces tight coupling.

Uncle Bob:

One of the problems with implementing an abstract class with inheritance is that the derived class is so tightly coupled to the base class

One of you is wrong, which is it?

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

Please answer this question… In your own words: I repeat - inheritance has absolutely nothing to do with coupling, therefore it is quite wrong to say that inheritance automatically produces tight coupling. and Neither of those articles put “inheritance” and “coupling” in the same sentence, so they are not related. Your article does not mention inheritance at all. and I understand that inheritance has absolutely nothing to do with coupling. Coupling only comes into play when one modul…

[tony_marston404]

@TomB

Robert C. Martin (Someone you often reference as an authority) says:

One of the problems with implementing an abstract class with inheritance is that the derived class is so tightly coupled to the base class

These opinions are clearly contradictory. Is Robert C. Martin wrong or are You?

The “coupling” which is produced when one module calls another is quite different from the “coupling” which is produced when one class inherits from another. It may be the same word, but they have different meanings in different contexts. As I have already pointed out from the article which you cited previously, when applying metrics to measure the theoretical quality of a piece of software, the effects of coupling resulting from inheritance can be excluded because they are irrelevant.

[TomB]

@tony_marston404

The “coupling” which is produced when one module calls another is quite different from the “coupling” which is produced when one class inherits from another. It may be the same word, but they have different meanings in different contexts. As I have already pointed out from the article which you cited previously, when applying metrics to measure the theoretical quality of a piece of software, the effects of coupling resulting from inheritance can be excluded because they are irrelevant.

Just answer the question… is Uncle Bob wrong or are you?

It’s been painfully apparent that we were discussing coupling in terms of OOP throughout the thread so no dice. And that’s wrong anyway because uncle bob points out, tight coupling is one of the problems cause by inheritance

[tony_marston404]

@TomB

What do you think $this->method() does when method is defined in the parent class? One “module” is calling another.

I disagree. Coupling only exists when one object calls another. When one class inherits from another the result is a single object, therefore there is no inter-object communication, therefore there is no coupling.

[TomB]

@tony_marston404

I disagree. Coupling only exists when one object calls another. When one class inherits from another the result is a single object, therefore there is no inter-object communication, therefore there is no coupling.

Just answer the question: Is Uncle Bob wrong or are you?

Tony Marston:

it is quite wrong to say that inheritance automatically produces tight coupling.

Uncle Bob:

One of the problems with implementing an abstract class with inheritance is that the derived class is so tightly coupled to the base class

One of you is wrong, which is it?

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

Please answer this question… In your own words: I repeat - inheritance has absolutely nothing to do with coupling, therefore it is quite wrong to say that inheritance automatically produces tight coupling. and Neither of those articles put “inheritance” and “coupling” in the same sentence, so they are not related. Your article does not mention inheritance at all. and I understand that inheritance has absolutely nothing to do with coupling. Coupling only comes into play when one modul…

[tony_marston404]

@TomB

@tony_marston404

No. It always comes down to the opinion of a human being, not the opinion of a machine.

And we get to see just how ridiculous you are. So the following pieces of code are exactly equal in quality? There is no way to objectively claim one is better than another?

$str =  'a';
$str .= 'b';
$str .=  'c';
$str .=  'd';
$str .=  'e';
$str .=  'f';
$str .=  'g';
echo strrev(strrev(implode(explode('', $str))));

echo 'abcdefg';

As an experienced programmer my personal opinion would be that the second piece of code is better than the first. My point is that you could not build a machine to make that same evaluation.

[TomB]

@tony_marston404

As an experienced programmer my personal opinion would be that the second piece of code is better than the first. My point is that you could not build a machine to make that same evaluation.

How are you deciding that the second is better? What metric are you using to determine that?

[tony_marston404]

@TomB

If you’d actually read what I wrote I pointed out that you have 400+ require_once lines which would be made redundant. The fact that these aren’t “at the top of a file” is 100% relevant.

They those statements are spread over a huge number of scripts, so I would have to refactor a huge number of scripts in order to use an autoloader. And for what benefit? Absolutely none, as the code would continue to do exactly what it did before, but do it differently.

@TomB

until you can provide a scenario where an autoloader is inferior in some way to hundreds of require_once lines your argument is invalid.

I never said that an autoloader is inferior to using include/require statements, I said that retrofitting an autoloader into a huge existing codebase would involve enormous costs but zero benefits. It is simply not worth the effort.

[tony_marston404]

@fretburner

Could you give a brief description of your understanding of what coupling means?

Coupling involves the amount of code required for one object to call another, and how this code would need to be modified following any changes made to either of these two objects. This is all explained in http://en.wikipedia.org/wiki/Coupling_(computer_programming) in which the word “inheritance” does not appear at all.

[TomB]

@tony_marston404

I never said that an autoloader is inferior to using include/require statements, I said that retrofitting an autoloader into a huge existing codebase would involve enormous costs but zero benefits. It is simply not worth the effort.

Stop backtracking please. Nobody is asking you to go back and change anything, we’re asking why you have actively avoided writing one for code you’ve written in the last 10 years. And don’t say you haven’t written a require line in 10 years as that’s just not true. If you diff two versions of your framework code it proves it…

[TomB]

@tony_marston404

Coupling involves the amount of code required for one object to call another, and how this code would need to be modified following any changes made to these two objects. This is all explained in http://en.wikipedia.org/wiki/Coupling_(computer_programming) in which the word “inheritance” does not appear at all.

So Wikipedia is now more authoritative than Robert. C. Martin?

Also, are you blind? From that exact page:

Subclass Coupling
Describes the relationship between a child and its parent. The child is connected to its parent, but the parent is not connected to the child.

[tony_marston404]

@TomB

Just answer the question… is Uncle Bob wrong or are you?

It’s been painfully apparent that we were discussing coupling in terms of OOP throughout the thread so no dice. And that’s wrong anyway because uncle bob points out, tight coupling is one of the problems cause by inheritance

See my answer in post #357

[s_molinari]

@tony_marston404

That is the most ridiculous statement I have ever read. 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:

Like I said earlier. SoC and SRP are two different things. We are talking about SRP, not SoC, so my statement is far from ridiculous.

Scott

[TomB]

@tony_marston404

See my answer in post #357

@tony_marston404

The “coupling” which is produced when one module calls another is quite different from the “coupling” which is produced when one class inherits from another. It may be the same word, but they have different meanings in different contexts. As I have already pointed out from the article which you cited previously, when applying metrics to measure the theoretical quality of a piece of software, the effects of coupling resulting from inheritance can be excluded because they are irrelevant.

The one where you didn’t answer the question at all?

Is Uncle Bob wrong or are you?

Tony Marston:

it is quite wrong to say that inheritance automatically produces tight coupling.

Uncle Bob:

One of the problems with implementing an abstract class with inheritance is that the derived class is so tightly coupled to the base class

One of you is wrong, which is it?

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

Please answer this question… In your own words: I repeat - inheritance has absolutely nothing to do with coupling, therefore it is quite wrong to say that inheritance automatically produces tight coupling. and Neither of those articles put “inheritance” and “coupling” in the same sentence, so they are not related. Your article does not mention inheritance at all. and I understand that inheritance has absolutely nothing to do with coupling. Coupling only comes into play when one modul…

[tony_marston404]

@TomB

tony_marston404:
As an experienced programmer my personal opinion would be that the second piece of code is better than the first. My point is that you could not build a machine to make that same evaluation.

How are you deciding that the second is better? What metric are you using to determine that?

Personal opinion which is backed up by several decades of experience. Both pieces of code produce the same result, but the second piece of code is by far the simplest. As a long time follower of the KISS principle the simplest solution which works will always get my vote.

[TomB]

@tony_marston404

Personal opinion which is backed up by several decades of experience. Both pieces of code produce the same result, but the second piece of code is by far the simplest. As a long time follower of the KISS principle the simplest solution which works will always get my vote.

I agree with you but let’s break that down a little: What is it that makes the second “simpler”?

[tony_marston404]

@TomB

tony_marston404:
I never said that an autoloader is inferior to using include/require statements, I said that retrofitting an autoloader into a huge existing codebase would involve enormous costs but zero benefits. It is simply not worth the effort.

Stop backtracking please. Nobody is asking you to go back and change anything, we’re asking why you have actively avoided writing one for code you’ve written in the last 10 years. And don’t say you haven’t written a require line in 10 years as that’s just not true. If you diff two versions of your framework code it proves it…

I am not backtracking, I do not write new applications from scratch, they are all built using my framework which was constructed years before autoloaders existed. That framework runs perfectly well without autoloaders, so refactoring it to use autoloaders is both unnecessary and economically unviable.

[fretburner]

@tony_marston404

They those statements are spread over a huge number of scripts, so I would have to refactor a huge number of scripts in order to use an autoloader. And for what benefit? Absolutely none, as the code would continue to do exactly what it did before, but do it differently.

You are missing the point by focusing on your own code as if it is the only PHP app that has ever or will ever be written. To any other developer reading this, the benefits to them should be obvious… if you had implemented an autoloader at the outset of your project (had autoloading been available) that would be 400+ lines you wouldn’t have had to write!