[prev in list] [next in list] [prev in thread] [next in thread] 

List:       groovy-dev
Subject:    Re: [groovy-dev] The evil static typing
From:       tugwilson <tug () wilson ! co ! uk>
Date:       2008-05-18 8:02:03
Message-ID: 17300157.post () talk ! nabble ! com
[Download RAW message or body]




Mark Haniford wrote:
> 
> With the rise of Groovy in the developer world, and the recent 
> discussions on the speed of Groovy I thought I would bring up the 
> subject of static typing in Groovy.  I can't find the link now (might've 
> been somewhere in roadmap over at codehaus, but I know I saw a note 
> about a possible "static" Groovy in the future?
> 
> We don't need dynamic typing for many of our objects, so my question is 
> how can Groovy get some static type inference without ruining it's 
> readability and expressiveness.  Or do you have to give up something?
> 


Firstly, please don't cross post on the dev and user group. Everybody who
can answer your question is subscribed to both and you will just fragment
the discussion.

It's possible to do type inference in Groovy but only to a *very* limited
extent.

def a = new MyObject()

can you guess the type of a? 

Well it turns out you can't be 100% sure that a contains an instance of
MyObject because I can catch the call to the constructor and return what I
like.

def b = 1

Yes in this case I can infer the type of b.

int x = 1

def y = x + 9


Nope I can't be 100% sure of the type of y because I can overload the +
operation on ints and return an arbitrary type.

Type inference in dynamic languages is *hard*. Every few years somebody
claims to have been able to do it for Python (I vividly remember Mike Salib
giving a wonderful presentation on a system he had "almost" working in 2004
- he's been a bit quiet since then).

In a language as dynamic as Groovy knowing the type of a variable does not
always help you improve performance. In some cases having to impose type on
a result makes the program slower.

int x = 1

x = x + 3

is currently *slower* than

def x = 1

x = x + 3

In the first case we have to check that the object which is the result of
adding 3 to x can be converted/unboxed to int before doing the assignment.
In the second case the assignment can happen with no extra work.

(this particular effect will probably disappear in the future but there are
other situations in which it's difficult to see haw to make the use of typed
variables as cheap as untyped ones).

John Wilson
-- 
View this message in context: http://www.nabble.com/The-evil-static-typing-tp17296887p17300157.html
Sent from the groovy - dev mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


[prev in list] [next in list] [prev in thread] [next in thread]