On Apr 24, 2009, at 12:35 AM, Robert Klemme wrote:

> Actually no.  My C++ is a bit rusty these days but if you do _not_
> declare a method as "virtual" and have a pointer of the base class
> type which points to a sub class instance the method invoked is
> actually the base class's method. This can only be remediated by late
> binding (declaring as "virtual") because only then the type of the
> object at hand decides about the method invoked.

One of the key benefits of polymorphism in the context of statically- 
typed languages is that you can pass around objects of a base type  
into functions. When one of the virtual (i.e., polymorphic) functions  
is invoked, the implementation appropriate to the object actually  
passed into the callee is invoked. In the context of a dynamically- 
typed language where method dispatch happens at runtime, this kind of  
polymorphism may not be as relevant.

The argument in favor of static typing has been had many times on this  
list, so I will only rehash it briefly: If you give a compiler some  
guidelines in a statically typed language, it can perform a boatload  
of optimizations based on things it can infer from size and behavior  
of data and it can do some measure of static type checking to increase  
the chances that the object you are operating on will support the  
method you intend to invoke with the given parameters.

The flip side is that you often find yourself doing "trust me"  
explicit type coercion and writing an extraordinary amount of code  
just to state an intent. That is an intent that can with a reasonable  
amount of care, testing, and clever language design be inferred. I  
know that is a bold statement and one that might be a bit contentious  
right now because of Twitter's assertion that moving to static typing  
saved them a ton of bugs. Static typing can slow velocity, increase  
the density of code, and decrease the readability because of all the  
required decorators.

Caveat: Just the opinion of an old grumpy ex-C++ programmer.