Syntax for abbreviated imports

[rjee]

Today we were looking at a feature request to abbreviate imports. The
issue explains it all:
http://code.google.com/p/projectlombok/issues/detail?id=290

The question was if we could somehow reduce the boilerplate in
situations where you use 2 classes in the same source file whose
simple name is identical (e.g. java.util.List and java.awt.List). If
you use these frequently, we can see that it can become quite
bothersome.

Using the technique described in:
http://groups.google.com/group/project-lombok/t/2c1b4249acd1286

We can introduce the following syntax:
@Import(ulist = java.util.List, awt = java.awt)
class Foo {
ulist bar = new ulist();
awt.List baz = new awt.List();
}

We're still investigating if we can let Eclipse auto-complete
appropriately and since this is quite a novel way of transforming the
file, we're going to make this a Beta feature (it might be dropped in
the future if it proves too dodgy).

what do you think?

[Leon Blakey]

Like the val operator, that does seem like a little too much magic.

--
You received this message because you are subscribed to the Google
Groups group for http://projectlombok.org/

To post to this group, send email to project...@googlegroups.com
To unsubscribe from this group, send email to
project-lombo...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/project-lombok?hl=en

[Reinier Zwitserloot]

I have this working like a swiss watch in eclipse right now. At least, for a subset of all type refs, but just some smart method extraction and it's done. I'm going to move on to javac first to confirm we can make this work in both platforms first.

[Philipp Eichhorn]

> what do you think?

I like it very much.

> I have this working like a swiss watch in eclipse right now.

Sound promising, can't wait to get my hands on this.

[Robbert Jan Grootjans]

Correct me if I'm wrong Reinier, since I haven't seen all the code
yet, but this uses quite a bit less magic than val. Incredibly
simplified, I'd say it substitutes certain identifiers with those
defined in the @Import tuples and is smart about remembering what he
did per compilation context. No resolution hanky-panky like was done
for val, this makes it a lot more testable.

[Reinier Zwitserloot]

The implementation is indeed much less magic. Relying on javac running annotation processors eventhough as far as it knows there's pure gobbledygook inside an annotation, that's a bit more magic.

 --Reinier Zwitserloot

[Reinier Zwitserloot]

Just shared the branch on github. It's named 'import'. Only Qualified references are updated, i.e:

@Import(awt = java.awt)

public class Foo {

    private awt.List listWidget;

}

that works.

@Import is also legal on methods. The replacements are applied to content of the annotated thing.

Next challenge is to replace SingleTypeReference with QualifiedTypeReference which is hard because eclipse's traversal isn't two-way like our AST. Fortunately the places where types can legally show up is limited. Also, for old versions of ecj, casts are done with NameReferences instead of TypeReferences but I'm not sure we should try to detect that and apply replacements in it, as newer versions of ecj fixed that bug.

 --Reinier Zwitserloot

[Jeremy Nimmer]

I like the syntax as well, and I am very excited to see this making
such amazing progress already! Sounds very promising.

I tried the branch and (at least in eclipse), it seems to work with a
two-deep package:
@Import(awt = java.awt)
but when I have a three-deep package like:
@Import(logging = java.util.logging)
eclipse just says "logging cannot be resolved to a type".

[Reinier Zwitserloot]

Actually, the auto-complete stuff isn't working at all right now, which means we need to do some work to make sure we can actually do this in eclipse.

The branch doesn't (yet) work for most things, just one thing, as a proof of concept; it can take qualified type references such as "foo.Bar" and replace the 'foo' part with whatever you want.