jastrachan | 18 Nov 08:46 2004

Re: Static dispatch and call semantics

On 17 Nov 2004, at 19:54, John Wilson wrote:
> On 17 Nov 2004, at 19:08, robert kuzelj wrote:
>> [snip]
>> It would appear that the calls of f on c must be implemented using 
>> dynamic dispatch.
>>> depending on the answers to my first set of questions I think I can 
>>> see a little problem ahead :)
>> why should there be? other compile time typed languages are very well 
>> able to to dispatch on the runtime time instead of the compiletime 
>> type
>> (as java does).
> Depending on the precise semantics of the language (i.e. depending on 
> the answers to my previous questions) it is possible that the 
> following code could produce different behaviour for the two calls
> any a = new MyClass()
> MySuperClass b = a
> a.f()	// dyamic dispatch
> b.f()  // static dispatch
> that is to say that the effect of making the same call on the same 
> object can be different depending on the type of the variable holding 
> the reference to the object.

No. This is just a virtual method call. No different to Java.

> My example shows that you can't always do static dispatch even if you 
> know the type of the object.

Not really.

> Note I'm building castles in the air here. I don't actually know what 
> the precise semantics of a call on an object held in a variable 
> declared with a type. It may be that there are a set of rule which 
> means that there is never a difference in the behaviour of static and 
> dynamic dispatch (i.e. it's a true optimisation).

The aim is to preserve method invocation semantics across both 
invocation mechanisms to avoid surprising the user. The aim of static 
typing is purely to catch typeos of passing in the wrong types of 
values or to mistype method names. Thats the aim here. We should try, 
wherever possible to maintain the behaviour of method dispatch, 
irrespective of how much static type checking a user is doing.