Re: [groovy-dev] making the bytecode generation more understandable

On 8 Oct 2004, at 11:43, Neil Ellis wrote:
> Sorry for the long email, please take the time to read though.
>> Pretty much ever point in the language, a type modifier is possible.
> So
>> for a variable, parameter, field you can specify the type. If you
>> specify that, then we can make static method invocations / field
>> accesses etc.
>
> But at the moment there is lots of downcast to Object and Invoker is
> used for all invocations, or am I wrong?

That's an implementation detail

>>> I would suggest that it would be quite difficult to have Groovy make
>>> compile time decisions without substantially changing the nature of
> the
>>> language.
>>
>
>> Why?
>
> At the moment there is lots of downcast to Object and Invoker is used
> for all invocations. This inherently means that Groovy code does not
> care about types,

Careful - don't confuse the language design with the current 
implementation of the bytecode generation.

> if Invoker has all objects downcast to Object it
> cannot care about types can it? (please correct if this is a
> misunderstanding on my part)

[snip]

> Okay so the first thing to comment on is that how will metaclasses work
> if the decision is made at compile time?

The metaClass is there mostly to assist in dynamic method dispatch. For 
static dispatch its not needed.

>  Metaclasses presume dynamic
> invocations. Second I can call floatValue on an int?

You mean would we be able to invoke new helper methods on JDK types - 
sure.

>  And thirdly in fact
> I can attempt to call any method on an object no matter what type I
> declare it as.

The idea was a variable would be statically bound to a type or its not. 
If you want to be dynamic you could always use a temporary object. i.e. 
if you don't want the constraints of static typing, don't use them.

>  Object o= new java.io.File("dave.txt")
>  println o.getName()
>
> This breaks the rules of static typing but runs fine in Groovy.

Yes - if you wanted to use dynamic typing, remove the Object (which 
isn't adding anything anyways)

> As I
> said, this means fundamental changes to the language.

No its not - its just a change to the implementation to do what it was 
always meant to do. If you specify a type declaration on a variable you 
are intentionally constraining its type and so Groovy should be able to 
make the computational savings that the constraint gives you. (i.e. use 
static method dispatch). This idea is essential to be able to export 
methods, fields, properties to Java code so that the bytecode has time 
information. So all we're doing is allowing static method dispatch to 
be performed *iff* you constrain things by type. The completely 
dynamically typed way of doing things is still possible.

>>> While types are deduced at runtime, reflective measures (such as the
>>> Invoker class) would seem a necessity and by nature these method
> calls
>>> will keep Groovy a little behind on performance.
>>>
>>> Basically the issue is that Java thinks in strongly typed compile
> time
>>> decisions and Groovy doesn't.
>>
>> No - Groovy can be used in both static or dynamic typed modes.
>
> James, I have suggested over the last few weeks/months to various
> individuals in the community that Groovy should support static/safe
> typing and the response has been that Groovy is a scripting language so
> forget it (but said more nicely than that  which is a decision I 
> have
> respected and have stopped pushing for Java style static typing.

All I can say is, why did we go to all the trouble of allowing 
properties, parameters, variables and fields to be constrained by type 
if we were not gonna use them.

> Where does Groovy stand? I started writing G because I felt Groovy
> wasn't going to cover the area I need (which is a replacement to Java
> basically - ie strongly typed safe, performant language). I have no 
> wish
> or desire to duplicate effort, and in fact started my work to look at
> alternative parsing strategies for Groovy - but from these emails I 
> feel
> very confused as to where Groovy is heading.
>
> At the moment all invocation is via the Invoker class and there is lots
> of downcast to Object so Groovy supporting static typing would be a
> major change wouldn't it?

Not really - its just a change to the bytecode generator. The parser & 
runtime & GDK would stay the same.

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