Explicit typing in Groovy: sometimes or never?

Question

[Later: Still can't figure out if Groovy has static typing (seems that it does not) or if the bytecode generated using explicit typing is different (seems that it is). Anyway, on to the question]

One of the main differences between Groovy and other dynamic languages -- or at least Ruby -- is that you can statically explicitly type variables when you want to.

That said, when should you use static typing in Groovy? Here are some possible answers I can think of:

1. Only when there's a performance problem. Statically typed variables are faster in Groovy. (or are they? some questions about this link)
2. On public interfaces (methods, fields) for classes, so you get autocomplete. Is this possible/true/totally wrong?
3. Never, it just clutters up code and defeats the purpose of using Groovy.
4. Yes when your classes will be inherited or used

I'm not just interested in what YOU do but more importantly what you've seen around in projects coded in Groovy. What's the norm?

Note: If this question is somehow wrong or misses some categories of static-dynamic, let me know and I'll fix it.

Answer 1

Groovy does not support static typing. See it for yourself:

public Foo func(Bar bar) {
  return bar
}
println("no static typing")

Save and compile that file and run it.

Answer 2

I have seen type information used primarily in service classes for public methods. Depending on how complex the parameter list is, even here I usually see just the return type typed. For example:

class WorkflowService {
    ....
    WorkItem getWorkItem(processNbr) throws WorkflowException {
        ...
        ...
    }
}

I think this is useful because it explicitly tells the user of the service what type they will be dealing with and does help with code assist in IDE's.

Answer 3

In my experience, there is no norm. Some use types a lot, some never use them. Personally, I always try to use types in my method signatures (for params and return values). For example I always write a method like this

Boolean doLogin(User user) {
// implementation omitted
}

Even though I could write it like this

def doLogin(user) {
// implementation omitted
}

I do this for these reasons:

1. Documentation: other developers (and myself) know what types will be provided and returned by the method without reading the implementation
2. Type Safety: although there is no compile-time checking in Groovy, if I call the statically typed version of doLogin with a non-User parameter it will fail immediately, so the problem is likely to be easy to fix. If I call the dynamically typed version, it will fail some time after the method is invoked, and the cause of the failure may not be immediately obvious.
3. Code Completion: this is particularly useful when using a good IDE (i.e. IntelliJ) as it can even provide completion for dynamically added methods such as domain class' dynamic finders

I also use types quite a bit within the implementation of my methods for the same reasons. In fact the only times I don't use types are:

1. I really want to support a wide range of types. For example, a method that converts a string to a number could also covert a collection or array of strings to numbers
2. Laziness! If the scope of a variable is very short, I already know which methods I want to call, and I don't already have the class imported, then declaring the type seems like more trouble than it's worth.

BTW, I wouldn't put too much faith in that blog post you've linked to claiming that typed Groovy is much faster than untyped Groovy. I've never heard that before, and I didn't find the evidence very convincing.

Answer 4

I worked on a several Groovy projects and we stuck to such conventions:

• All types in public methods must be specified.

  public int getAgeOfUser(String userName){ ... }

• All private variables are declared using the def keyword.

These conventions allow you to achieve many things.

First of all, if you use joint compilation your java code will be able to interact with your groovy code easily. Secondly, such explicit declarations make code in large projects more readable and sustainable. And of-course auto-completion is an important benefit too.

On the other hand, the scope of a method is usually quite small that you don't need to declare types explicitly. By the way, modern IDEs can auto-complete your local variables even if you use defs.