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

On 7 Jul 2004, at 16:29, John Wilson wrote:

>
> On 7 Jul 2004, at 15:56, jastrachan@... wrote:
>
>>
>> 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.
>
> But you can't, in general, tell at compile time what methods there are 
> on something of type Object (i.e. something created using new 
> Object()). This is because a use clause can dynamically add methods to 
> *any* class. You can't, in general, tell what objects are going to be 
> enhanced by a use clause because it takes an instanced of 
> java.lang.Class or a List so it can be dynamically specified at run 
> time.

Sure - though most use clauses can be evaluated at compile time. The 
whole point of using static typing (as opposed to the implementation 
under the covers using static method dispatch) is so that the compiler 
checks what methods you're calling at compile time. So if someone wants 
to use static typing, with an object of type Object, I'd expect that to 
occur. i.e. Object is just a type like any other, its not special other 
than its the root of the hierarchy.

Up to now I'd assumed...

// dynamically typed
x = new Object()

// statically typed - can only invoke Object methods on y
Object y = new Object()

Whether we use a keyword 'any' or not I'm not sure but I like the idea 
of allowing static type checking at compile time if developers wish to 
enable it. This is a different conversation to optimising the code to 
use static method dispatching when the compiler/runtime can figure that 
out.

> I think you have to do dynamic dispatch for unknown methods on known 
> types inside use clauses. If you have to do it there then you really 
> should do it everywhere otherwise it gets too confusing for the user.

I think we can support both modes. The specifying of the type 
restriction should invoke compile time static type checking. Otherwise 
there's no point specifying the types of things :)

>>> 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).
>>
>
> I'm not sure I follow what you don't follow :))

:)

> I think we are discussing Bing's static type inference and the impact 
> it has on method dispatch. You were proposing (I think) a keyword to 
> suppress static method dispatch even if the type was known or could be 
> inferred.

I wasn't really talking about whether or not we use static method 
dispatch under the covers - I was more talking about whether or not we 
do static type checking at compile time.

>  I was trying to show that Object would do instead because it can't 
> use static dispatch (except in the case where the value was known to 
> be created as new Object()) on anything declared as Object anyway.
>
> in the case of:
>
> final Object o = new MyClass()
>
> you can in principle use static dispatch of known methods. However 
> it's a rather odd use of Object.

I frequently in Java use static typing on Object. e.g. toString(), 
wait(), notify(). Often we'll use an Object in a statically typed way 
just to be a semaphore/lock.

I think it'd be more surprising to disable static type checking at 
compile time on things of type Object.

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