C# -- the Java killer?

Godmar Back gback@cs.utah.edu
Tue Jun 27 13:26:00 GMT 2000


> 
>   * Virtual methods are supported but you have to use the 'virtual' and
>     'override' keywords - a bit ugly. Otherwise methods are treated as
>     non-virtual. My guess is that they are trying to avoid the problem
>     that Java has with nearly everything being a virtual method, and the
>     resulting performance issues. However, a static C# compiler should be
>     able to devirtualize everything since there's no dynamic class loading.
> 

Actually, this choice is something I very much agree with.
I think that Java got it wrong when it made "virtual" the default.
The performance issues you mention are the least of my concerns.

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.

	- Godmar



More information about the Java mailing list