The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I disagree with you about everything being extensible, but that part about instances having different exposure than the class definitions is brilliant. And I like the idea of having only methods be able to be public.

While I'm typing, I've always thought that "protected" was a terrible choice of word to describe what it does. (Hell, isn't "protected" practically a synonym for "private".) My word for that would have been "family".

I disagree with you about everything being extensible, but that part about instances having different exposure than the class definitions is brilliant.

Uhh...
Thanks, I guess.

Anyway, the reasoning behind everything being extensible is this: In OOP, each object represents, well, an object -- often an abstract one, but sometimes a real one (let's say, a duck). The problem is that too many times we get sidetracked by the classes, and forget that it's the actual objects that matter; and further, we get sidetracked by the implementation details and forget that they're not important.

The only situation where there should be any inheritance is when the subclass actually represent a sub-type of its parent. I know that this is a too rigid and exclusive standpoint, and in real situations I dismiss it as well, but ideally, this is all that makes sense. Imagine that we have "limp ducks", which are a subspecies of "normal" ducks, differing from them only by, say, not being able to fly. They share all their other properties, and in programming terms we say that the subclass inherits them and changes those that differ. The current "private" keyword was developed as being as rigid as it is in most modern language as a (bad) way to prevent bad programmers from doing harm, not to promote OOP principles.

Originally Posted by Rotwang

And I like the idea of having only methods be able to be public.

While I'm typing, I've always thought that "protected" was a terrible choice of word to describe what it does. (Hell, isn't "protected" practically a synonym for "private".) My word for that would have been "family".

Actually, I was thinking more along the lines of "default" (i.e. having no special keyword) and "public". Unlike most modern OOP languages, I would set "private" to be the default, with only those properties that we want exposed as "public" -- i.e. the API. This way we care only about an object's behavior, and we don't really care about its internals.

And I was partially wrong in the previous post, as there is one language that comes close to what I described, and that is Javascript.

The only situation where there should be any inheritance is when the subclass actually represent a sub-type of its parent.

Concrete class inheritance (Eg. class Foo extends Bar) really does two things at once. 1) Foo inherits the type of Bar (type inheritance) and 2) Foo inherits the implementation of Bar (implementation inheritance). It's unfortunate that the language semantics mix the two things together, since they are really two completely separate issues.

Theoretically, type inheritance is very useful, since it allows polymorphism, whereas implementation inheritance is an ugly hack. Like many ugly hacks, it's sometimes useful in the real world, even if it's impure from a scientific point of view. It can always be replaced with composition, but it may take a little more effort. The more experienced people become with OOP, the more they tend to avoid implementation inheritance, and use composition instead.

Pure type inheritance can be achieved in statically typed languages through interfaces, and in the case of dynamically typed languages such as PHP, by magic. The conclusion on this would be that inheritance is completely unneeded in PHP, unless for nasty shortcuts. Then again; Some would argue that PHP is the incarnation of ugly shortcuts in the first place.

Pure type inheritance can be achieved in statically typed languages through interfaces, and in the case of dynamically typed languages such as PHP, by magic. The conclusion on this would be that inheritance is completely unneeded in PHP, unless for nasty shortcuts. Then again; Some would argue that PHP is the incarnation of ugly shortcuts in the first place.

Good post. But in a way, if you're against implementation inheritance, then you're really against inheritance in general, and rather, in favor of using interfaces instead, right? One could say that an interface is like inheritance without the implementation, no?

My view is implementation inheritance is ok if the class being inherited from explicitly expects (and allows) it, and was created with the intention of being extended.

Also you're venturing onto the strong typing debate . (I think the worst thing about php/python is the weak typing. Oh, excuse me, "dynamic typing", the politically correct term. (Well, actually the worst thing about python is the whitespace thing, but now I'm in double perens.)) Much like the original post, one could say, as you kind of did, "why bother creating interfaces in php? it will work anyway if you don't." The original poster asked "why bother declaring public...". I want all those declarations to be required, as in java or AS 2/3...

One could say that an interface is like inheritance without the implementation, no?

Yes, that's exactly the case. And when BerislavLopac says that inheritance should always follow the is-a principle, he's really suggesting that inheritance should only be used if you intend to both inherit the type and the implementation. If you only need one of those feats, you should either use interfaces (type inheritance) or composition (implementation inheritance). As I already mentioned, interfaces are redundant in PHP, so in the first case, you should simply do nothing.

Originally Posted by Rotwang

But in a way, if you're against implementation inheritance, then you're really against inheritance in general, and rather, in favor of using interfaces instead, right?

My view is implementation inheritance is ok if the class being inherited from explicitly expects (and allows) it, and was created with the intention of being extended.

I may have been unclear about it, but I agree that implementation inheritance has it uses. It's for pragmatic reasons more than theoretical though. Some languages have other means for reuse of implementation than inheritance. I believe constructs such as mixins are an attempt to solve this issue in a more elegant way. However, we must work with the tools which the language supports, and that means inheritance.

Originally Posted by Rotwang

Also you're venturing onto the strong typing debate . (I think the worst thing about php/python is the weak typing. Oh, excuse me, "dynamic typing", the politically correct term. (Well, actually the worst thing about python is the whitespace thing, but now I'm in double perens.))

Much like the original post, one could say, as you kind of did, "why bother creating interfaces in php? it will work anyway if you don't." The original poster asked "why bother declaring public...". I want all those declarations to be required, as in java or AS 2/3...

The whole static vs. dynamic type debate is an old one. PHP is an interesting case, since it's initially on the dynamic side of the fence, but the class system, which was inherited from Java, has pulled it in the opposite direction -- Most notably with typehints. This is a natural consequence of mixing oil and water, but exactly therefore, I don't think these constructs will ever become mandatory in PHP. The lesson, I think, is that PHP supports multiple paradigms; You can mix procedural with object oriented and statical typing with dynamic typing. This is a great strength of the language, but it means that you have to relax a bit on theories, since you have contradictory forces working within the same context.