jastrachan | 14 Jul 13:40 2004

Re: [groovy-dev] "the type of an untyped variable". was RE: [groovy-dev] Re: [groovy-jsr] Re: [groovy-dev] static binding subsystem for better performance

On 14 Jul 2004, at 07:01, bing ran wrote:
> As of the current CVS, when -Dstatic.dispatching=true, an untyped 
> variable
> gains types by:
> 1. being initialized by a clearly typed constant. e.g.,  a = "hello"
> 2. being assigned with another variable that has type description.  
> e.g., b
> = a
> 3. being initialized with a new instance of a class. e.g., c = new
> File("file name")
> 4. being assigned with the return value of a method call that can be
> resolved at compile time. e.g.,  s = a.toString()
> otherwise it remains as an Object internally.
> One thing notable is that a variable that is not statically typed can 
> take
> different types along the code flow:
> a = "Hello"
> ...
> a = 123
> I guess this what people call "dynamic typing". I'm just not sure how 
> useful
> this is. For me this is usually an indication of chaos in mind:)


I think this kind of thing is the exceptional case, but we should be 
able to handle it. i.e. if someone changes from String to Number, then 
the static-type (at the implementation level) is Object & we use 
dynamic method dispatch.

> Unless we want to make Groovy a "container", personally I don't see 
> why one
> would ask to go though late binding if early binding can be done at 
> compile
> time, with the builder stuff as an exception.

I agree - wherever possible we should use static method dispatch under 
the covers when we know its safe to do so.

> Interceptions can be achieved when Groovy classes are deployed to 
> containers
> that offer the service, such as Spring.