How should overruling of overloaded functions work?

[Bruno Medeiros]

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 at 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