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

They often signal that the components wired together represent different or independent concepts or responsibilities, or belong to different abstraction layers in the system.

Scott

As I said nobody is asking you to rewrite the existing lines but you’ve written require_once lines enough times in the last 10 years to have made that time pay off. Once you’ve written an autoloader you don’t need to touch it again, with require_once you need to type it out every time and look up/mull over what the name of the file the class is stored in is. Not to mention, require_once lines take up screen space meaning that you’ll have spent more time mentally scrolling past them than you otherwise would have to had.

Not to be pedantic, but this has to be one of the DUMBEST reasons I’ve ever heard as to why a person would want to change a piece of code.

3 Likes

I never said anything about retrospectively changing anything, I was just pointing out that writing require_once lines instead of using an autoloader will have other knock on effects with regard to development time than just typing out the line. In tony’s words using an autoloader is “economically unviable.” and has been for 10+ years. The time saved by using an autoloader 10 years ago would have paid for itself dozens or hundreds of times over.

Does not your IDE have auto-complete?

It certainly doesn’t know the file name I’m about to type… Even if it magically did, clicking a button/pressing a key to autocomplete still takes time that wouldn’t be spent when using an autoloader. (And writing an autoloader for tony’s code would take all of about 10 seconds given his class/file structure here: http://pastebin.com/31sHHv75 )

In this instance, yes. Just because I agree with some of the things which Uncle Bob says does not mean that I have to agree with everything he says.

I still maintain that the coupling which results from one object calling another is completely different from the coupling which is produced from one class inheriting from another. Same word, but different meanings in different contexts.

That article also states the following

This means that even if there is coupling between a superclass and its subclass, it would be wrong to state that the level of coupling would automatically be tight.

How are they different?

He is.

Aha excellent so we can now ignore any article you bring up citing uncle bob as he’s clearly not a trustworthy source.

Again, Uncle Bob and everyone else disagrees with you. The reason for that is that the implementation is fixed to a very specific one $this->method() will always call the same implementation of a method (it’s tightly coupled) $this->foo->method() can call one of many possible implementations, it’s loosely coupled.

And so much backtracking. So now there is coupling but it’s not tight? What is the difference between tight and lose coupling in your mind, give me a code example of each.

As a starting point, do you now admit these two things you said are painfully wrong?

Neither of those articles put “inheritance” and “coupling” in the same sentence, so they are not related.

and

I understand that inheritance has absolutely nothing to do with coupling.

Because if so, you’re finally admitting you don’t understand coupling.

edit: Here are some more sources for inheritance = tightly coupled

http://www.agile-code.com/blog/composition-over-inheritance/

http://c2.com/cgi/wiki?InheritanceBreaksEncapsulation

Inheritance creates a tight coupling between base and derived classes.

http://www.artima.com/cppsource/codestandards3.html

Avoid inheritance taxes: Inheritance is the second-tightest coupling relationship in C++, second only to friendship. Tight coupling is undesirable and should be avoided where possible.

Please find me some sources that claim inheritance is “loose coupling”.

If autoloaders had been available when I created my framework then I would have used them. But they weren’t, so I couldn’t. Instead I used what was available, and that method still works just as good now as it did then.

PHP5 was release in 2004. Even if you supported PHP4 until 2010 that’s still 5 years where you could have used an autoloader and chose not to. In 20 years time will you have implemented one? Even if only you write one requre_once line every 6 months it will only take a couple of years for the time spent typing out the lines to total more than the 10 seconds it would take to write an autoloader.

edit:

given the autoloader

function __autoload($name) {
	require_once $name . '.class.php';
}

This is 60 characters. Given an average class name of 10 characters e.g. require_once '1234567890.class.php'; the line is 36 characters. By the time you have written two require_once lines the autoloader has paid for itself.

1 Like

Just because some people say that inheritance produces tight coupling does not mean that everyone agrees. And unless you can point to the “problems” caused by inheritance which means that it shouldn’t be used at all your argument has no point at all. If it is so much of a problem then inheritance wouldn’t be allowed at all, which would completely destroy the whole concept behind OOP. Next you will be telling me that polymorphism produces tight coupling or somesuch and should be avoided as well. Perhaps the only way we can avoid the problems produced by OOP is to abandon the whole idea and go back to procedural programming.

And now you’re backtracking and moving the goalposts. Does inheritance create coupling or not? Do you admit these statements you made are wrong:

Neither of those articles put “inheritance” and “coupling” in the same sentence, so they are not related.

and

I understand that inheritance has absolutely nothing to do with coupling.

http://www.objectmentor.com/resources/articles/inheritanceVsDelegation
https://groups.google.com/forum/#!topic/comp.object/Kz3bBzSf9t0
http://codingdelight.com/2014/01/16/favor-composition-over-inheritance-part-1/
http://blog.berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/
http://misko.hevery.com/2008/07/30/top-10-things-which-make-your-code-hard-to-test/

Robert C. Martin again:

Inheritance it the tightest bound relationship there is.

Is that enough reasons for you?

I think this blog hits the spot.

And now that I think about it, your monster class breaks both.

Scott

So is that an admittance, that you would agree, when I say, autoloaders aren’t just a fad, but a decent improvement to PHP?

Scott

1 Like

And you’re wrong. Economics is a science. Specifically a social science about the value of things. Things which are better (or at least perceived as such) command a higher price in a free market.

Oh my. :flushed:

Scott

That is probably because you and your cohorts made one or both of the following mistakes:
(a) You failed to build an application structure that could easily be enhanced and extended.
(b) You failed to apply enhancements or extensions in a proper manner which resulted in the application being slowly degraded over time.

I do not suffer from such failings. The application structure which I created all those years ago is still going strong despite undergoing monthly enhancements. The enterprise application which I started in 2007 is still going strong despite the original subsystems being extended and new subsystems being added. That code is just as easy to work on now as it was then. While your legacy software is fit for nothing but the scrap heap, my software is still as sound as a bell and as fresh as a daisy.

But that’s only my opinion, and as a heretic and a non-believer I know that my opinions don’t count in this forum. But do I care?

I am extremely disappointed in a lot of you on this thread.

Aristotle has a famous phrase, “it is the mark of an educated mind to entertain a thought without accepting it.”

Essentially it means that while you may not agree with someone’s opinion, you can still be capable of discussing it.

Let me make this very, very clear.

Disagree with a thought all you want. Argue until we run out of server space. Go for it. But do not personally insult another person on this forum. Not only is it against our rules, it’s against human decency. Insult the argument but not the person.

If the only way you can defend your own thoughts, code, or beliefs on this forum is to insult the person you’re talking to, you’re not welcome here.

10 Likes