C# -- the Java killer?

Cliff Draper Cliff.Draper@Sun.com
Tue Jun 27 16:27:00 GMT 2000


From: Godmar Back <gback@cs.utah.edu>
Date: Tue, 27 Jun 2000 14:26:21 -0600 (MDT)
> The primary problem is that virtual methods are error-prone.  They 
> can easily break base classes if a subclass that overrides a method
> does not implement the contract of the overridden method 100%, which
> frequently happens.  Especially in closed-source (or bytecode only)
> base systems where you extend classes in the "programming by difference"
> paradigm such mistakes are hard to impossible to track down.
> 
> Granted, having to declare a function "virtual" does not guard against
> such mistakes.  But at least it puts up a warning sign that tells the
> implementor to be especially careful when defining that method's semantics,
> and it tells the caller to not rely on hidden knowledge about their
> implementation.  
> 
> In essence, it's an issue of deciding what's the normal, common case, 
> which requires less attention, and what is the less common case which,
> because of its semantic implications, needs conscientious attention 
> when used.

I think "virtual" is the best default choice.  There have been way too
many times in C++ when I wanted to override a method in a class, but
couldn't because the author (presumably) forgot to make the class
extendable.  Same thing for Java, someone marked a method as final
making it no longer extendable, but I really did want to extend it.  I
had to dump that class and write my own code that I could extend
(there's a clear lack of reusability!).

With modern dynamic compilers, the performance problem with "virtual"
methods goes away.  HotSpot currently does a great job of this, and
will do even better in the future.  This allows developers to think
more object-orientatedly.  (See talk about HotSpot from JavaOne.)

Now, the problem that was brought up, is that base classes can break
because of incorrectly coded overriding.  This sounds like a clear
case for preconditions, postconditions, and invariants to me.  They
help specify the contract of what that method is suppose to do.  All
clients of that method will expect that method to uphold its contract,
whether that method is from the base class or from an overriding
class.

Cliff Draper        Sun Microsystems, Forte Tools        (510) 869-3462
My opinion may differ from my employer.
---------------------------- food for thought -------------------------
May the forces of evil become confused on the way to your house.
                              -- George Carlin


More information about the Java mailing list