@Jonah
Looks like I've gotten sucked into the conversation
josh wrote:robot cannot inherit animal because robots aren't organisms! They shouldn't breathe() and sleep()!!! You're going to print_r() your object and get loads of unrelated information. That's a big code smell.
Right. That's a situation where normal inheritance can't cut it, and composition saves the day.
josh wrote:4 ways to define a class in javascript? I know of only one, 'function'.
I think he means like this:
Code: Select all
var MyClass = function () {
this.something = function () {
// ...
}
}
// or
var MyClass = {};
MyClass.prototype.something = function () {
// ...
}
In javascript there is one way to define a class IMO, which is to create a function with closures. The essence of prototypical inheritance is adding methods to a class after it's defined, I don't really count that as a second method but even if I did that's still not 4 methods
For one, if you want to name a method the same as a parent class's method, it seems likely that you know it, and want to override it. And two, any IDE can tell you if the method names are in conflict pretty much instantly. Netbeans for example puts a green circle with an "I" in it beside any overriding method.
It seems likely I'll know it? The example I gave was to point out that you may not.
And not any IDE can show you when methods are in conflict. Only netbeans that I know of, and my netbeans project cache always seems to go bad and code completion and the like stop working. I also work with a guy who uses vim, he refuses to use IDEs, you could have team mates like that some day...
So you're saying that we should use 100% composition because we might need what it provides sometime in the future?
I wouldn't say that you should use 100% composition just because you might need it.. I wouldn't go as far as making a hard & fast "rule", however inheritance is a code smell. The further from 100% you get, the less I like your code
Seems like it would be pretty clear cut when a class hierarchy is going to need the functionality that only composition can provide right off the bat.
Well again, objects model concepts in our brain, which don't exist in a hierarchy. While you
may be able to implement as a hierarchy at first, there is a high likelyhood of a user request that contradicts that. I don't know about you but I'd rather not tell my customer he has to pay extra for his feature because it doesn't fit into the way I envisioned the objects working a year ago.
And how do abstract classes make refactoring difficult?
They don't, but refactoring from an abstract class to composition is easier than just refactoring composition.
@Vlad
You can not argue against abstract classes, saying some features are missing, and then say that implementing these features sucks because their purpose is to serve abstract classes.
I didn't. A virtual method is the same thing as an abstract method, we already have it. It doesn't address any of the problems with abstract classes, it just encourages programmers to use more abstract classes (making their inherent problems more rampant!). If one of the things you listed means the same as prototypical inheritance then that one I'd be in favor of. In prototypical inheritance there are NO abstract classes though, I am AGAINST abstract classes.
Christopher wrote:I think the argument is whether (in PHP) that inheritance should ever be used. My conjecture was that there are common use cases where (in PHP) inheritance can do the same thing as composition but with simpler syntax and less work.
I don't think anyone said it should not be used, I did however say that implementing your code in this way limits your ability to add certain features in the future. Its the same as global variables, static code, or singletons. They have a use and they also have drawbacks. There are also alternative ways to structure your code that have the same uses with less drawbacks. Hence why more experienced programmers recommend staying away from those particular features.
@Jenk
Heh, it's certainly digressed from the original topic anyway
In the same way your code needs to digress from a strict hierarchy sometimes your thread has to digress. lol. I'd be against splitting the thread though, unless the OP requests it.
But on that note, I try to avoid inheritance where possible.
I'd agree except for the "where possible", that implies inheritance is needed, which it is not

Wanted? Sure. Needed? No. I have a need for objects because I can't structure code w/o them, there is no physical way to do it. I only "want" inheritance though, I don't need it.