Christopher wrote:josh wrote:A variable is a implementation detail. Objects are accessed by variables. Variables are implementation details.
I think you are just making things up at this point!. Do you mean properties? So if object $foo has a property $bar then both $foo and $foo->bar are variables. Certainly $foo is not an implementation detail.
Yes $foo is an implementation detail in the
calling code. Obviously when you do:
$foo = new Foo;
That is not part of Foo's implementation. However you are now implementing code in the global space.
http://stackoverflow.com/questions/1777 ... ion-detail
Basically what stack overflow says, if i can summarize. "implementation details are anything not in your client's spec (like the name of a class, method, or variable), so if you rely on something like a variable name your code is not guaranteed to work with other code written to the same specifications"
Christopher wrote:So you have now turned everything into implementation making the words meaningless. I think when you type "class Foo" you have not yet got to the implementation -- which is the stuff in the class block.
Really? Why do programmers like Martin Fowler and you use terms like "implementation language"??
Christopher wrote:I am not a big fan of abstract classes either. But I don't understand how the the diamond problem of multiple inheritance relates to this discussion because PHP only has single inheritance
When I say diamond problem refer back to my example about robot, cat & dog, all walk but robot should not inherit from the same super class as animals. Single or multiple inheritance, it doesn't matter because neither can solve that problem.
And yes, prototypical inheritance has the advantages you mention. However in relation to this discussion the practical disadvantage of prototypes is the increased verbosity over conventional classes and inheritance.
What increased verbosity??
Again, that is my point. It is not that traditional inheritance is better. It is that it is simpler for many common cases.
Well this part I've agreed with. It can be easier to read & write in a simpler program. But you know what else is simpler for many common cases? Singletons, global variables, etc.

To me this discussion seems just like the discussions about global variables. Everyone who uses them seems to think their simplicity outweighs the propensity to shoot yourself in the foot. I simply disagree out of experience.
And that simplicity and parse-time checks may support correctness
Code: Select all
class Foo {}
class Bar extends Foo {}
$foo = new Bar;
$foo->bar();
Here the compiler does nothing to warn you that you're calling a method on Bar instead of Foo, so I'm not sure what your repeated rebuttal about calling "parent::" is about. If a method is overridden, you definitely need to be conscious of that.
Interesting discussion though, keep it going. Its getting very philosophical. These are the threads I like.