Re: [groovy-dev] static binding subsystem for better performance

On 7 Jul 2004, at 15:37, John Wilson wrote:

>
> On 7 Jul 2004, at 15:21, jastrachan@... wrote:
>
>>
>> On 7 Jul 2004, at 15:15, John Wilson wrote:
>>> On 7 Jul 2004, at 14:37, jastrachan@... wrote:
>>>
>>>> One minor thought...
>>>>
>>>> [snip]
>>>
>>>> In static typing mode we should be checking the methods are correct 
>>>> at compile time & giving a nice error if they're not - this is one 
>>>> of the main aims of static typing afterall. (Whether we're in 
>>>> static typing or dynamic typing, the compiler/runtime can get 
>>>> clever & do static method dispatch but I consider that an 
>>>> optimisation).  So if you declare a variable to be of type Object 
>>>> and then call some method foo() it should probably barf & fail to 
>>>> compile rather than quietly going into dynamic typing mode.
>>>>
>>>> Maybe we should use a magic type name of 'any' to indicate that you 
>>>> definitely want to be dynamically typed?
>>>>
>>>
>>> Doesn't the non magic type name Object do that already?
>>
>> It shouldn't, as Object is a valid statically typed type. Sometimes I 
>> want an object of type Object and to use static method dispatch on 
>> it. e.g. when using an object as a lock & calling its wait() / 
>> notify() methods.
>>
>
> Two cases here:
>

1)

> Object o = new Object()
>
> all calls on o can be safely statically dispatched - you don't ever 
> want to to dynamic calls on one of these.

2)

> Object o = new MyClass()

Or case 3

o = new MyClass()
o = someOtherRandomThing

> I think Bing will always use dynamic dispatch here.

There's a big difference between the implementation choosing to use 
static/dynamic dispatch for performance and the compiler working in a 
static or dynamically typed way.

In cases 1 & 2 I'd like - eventually - the compiler to fail to parse & 
generate a meaningful compiler error message if the user attempts to 
call a non-Object method. In case 3 it'd be runtime exception if you 
call a method which doesn't exist on MyClass or someOtherRandomThing 
etc.

> In this simple case he could, in theory, use static dispatch but if o 
> was a parameter to a function he would have no way of telling if the 
> actual object passed was some wacky superclass of Object which did 
> fancy stuff with method calls.
>
> So a rule which said that you always do dynamic dispatch on Objects 
> unless you *know* they are only an Object would give the functionality 
> you are after without introducing  another keyword.

Not sure I follow. Static & dynamic typing at compile time is quite 
different from how the bytecode dispatches the method (using static or 
dynamic dispatch).

James
-------
http://radio.weblogs.com/0112098/