Søren J. Løvborg wrote:
> This is the old problem of modifying the base class, while having the subclass continue to work as it should. It manifests itself in many ways.
> 
> The only way one can be sure to avoid this problem, is to never extend a class that one does not control -- i.e. classes defined in libraries etc.
> 
> If this rule is followed, there's indeed no reason for the current (C++ like) hiding of overloaded functions.
> 
> See for instance, "Why extends is evil" at JavaWorld, discussing the "fragile base-class" problem.
> http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html
> 
> Quote:
>> I once attended a Java user group meeting where James Gosling
>> (Java's inventor) was the featured speaker. During the memorable
>> Q&A session, someone asked him: "If you could do Java over again,
>> what would you change?" "I'd leave out classes," he replied.
> 
> It's a controversial topic. :-)
> 
> Søren J. Løvborg
> web@kwi.dk 
> 
> 

The thing about classes and direct inheritance is that there is intrinsically a strong coupling between the derived and the parent class. And, since strong coupling should be minimized, he argues that direct inheritance is "evil" and should not be used, but such a blanket, generalizing statement can only be considered idiotic. Sure, there are disadvantages in using direct inheritance, so one must me aware of such disadvantages, and use "extends" only when appropriate, but that doesn't mean never use it at all. (just as many other things that should be used with parsimony)

The second problem mentioned, which the author failed to conceptualize correctly, is that a derived class should respect the "is-a" behavior in order to be safe. (Behavior in other words is the class's contracts, whether explicitly specified in the code or not.)
If one doesn't do that (which he didn't in his examples), then polymorphic behavior becomes unsafe. But again that's not the fault of direct inheritance, it's the fault of not using it appropriately. For more info on this "is-a" problem, check this page about such subtyping problems: http://okmij.org/ftp/Computation/Subtyping
[Design by Contract in a methodology to take this formalization of class's contracts and how they should work with inheritance, and allow to specify and verify such contracts in the code, which otherwise are often left specified only in documentation, people's mind, or not at all]

But in any case, this does not justify the current behavior of the overriding of overloaded functions. The coupling between derived and parent classes is *intrinsically* very strong, and *any* kind of modification to the base class (or for that matter, in the derived class as well) is passible of having many repercussions, some of them possibly surprising and undesired. But there is no way around it. Why should the language try to "fix" just one particular and specific case of changing the base class without having to check the repercussions on derived classes, when:
a) such "fix" may not be valid at all: if a base class is changed, especially the public or protected API of it, it's likely the derived classes should be checked anyway, and trying to prevented that may not be correct.
b) the "fix" introduces surprising and/or annoying behavior in other situations, namely regular overriding of overloaded functions.

Also (like point 2 Kristian mentioned) the "fix" breaks IMO a basic "rule" of polymorphic behavior of classes: for an the object whose runtime type is the same, it does different behavior for a virtual function call depending on the static type of the object. Like "foo.func()" will do different things whether foo's static type is Foo or FooBar, despite the instance runtime type being FooBar in any case. This IMO should not happen.

Java works this way, and C# too, (although C# has one other quirk which, unless there is some obscure reason for it, can only be considered idiotic: http://blogs.msdn.com/nealho/archive/2006/01/19/515173.aspx )

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D