14 Jul 2004 13:40
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.
Agreed.
James
-------
http://radio.weblogs.com/0112098/
RSS Feed