Otaku, Cedric's weblog

Groovy and renaming imports

I really like what Groovy is turning into.  Closures are definitely the most important thing in my eyes, but I can understand that the value of such a feature can be puzzling for you until you try a language like Ruby.  I have also been very impressed by the choice of features that James has made so far and I agree with pretty much all of them.  Except maybe for this one.

import java.util.Date;
import java.sql.Date as SqlDate

I have seen "import renaming" at work with Eiffel and it's not pretty.  It's a good example of a feature that sounds good in theory but ends up making your code very hard to read and to maintain.  Note that Eiffel was worse in that respect because it also allowed to rename methods when you import them (a feature that, unfortunately, Ruby supports as well).

What problem are we trying to solve exactly?

Sometimes, you have to create a class that already exists, either in java.lang or elsewhere.  And before you jump the gun and say "just make sure it doesn't happen", you need to realize that you don't always have a choice since these classes might have been generated by a tool that doesn't allow you to customize its mapping (such as an XML-Java mapping tool for example).

I would argue that in such a case, it's much clearer to require the developer to fully qualify both colliding names in order to clear up the ambiguity:

java.lang.Number n1 = ...;
com.foo.Number n2 = ...;

instead of using a random renaming which is local to the compilation unit and can vary depending on who is writing it:

MyNumber n1 = ...;   // java.lang or com.foo?  Need to check the import

I will also observe that in my experience, such cases are rare.  Adding a feature to a language in order to address a rare case is a dangerous slope that Groovy should avoid at all costs.

I think Groovy has tremendous potential, which is already showing thanks to its ability to compile to bytecode directly, hence making it useful to Groovy fans and non-fans alike.  But Groovy's biggest challenge still lies ahead and James and his team will have to be very vigilant that any new feature they add to it obeys the "80/20" rule:  solve 80% of the problems with 20% of the work.

Based on what I've seen so far, I am confident James is up to the task.

Posted by cedric at December 16, 2003 08:33 AM