@Delegate, @Mixin and Duby Closures

[McKinley]

Are @Delegate and @Mixin ready or otherwise available in SCM? I have
seen talk of them but I do not see them in the documentation.

Also, FYI here are some notes on the Java behind closures in the to-
bytecode or to-Java-source compiler for the Duby language. I like that
they are allowing access to variables inside and outside the closure
and thought others might find it interesting. It is the type of
implementation that would be hell to code which makes me think of
Lombok to make it automatic.

http://kenai.com/projects/duby/pages/DubyBlocks
http://threebrothers.org/brendan/blog/closures-in-java-ruby-and-duby/

Thanks,

McKinley

[Reinier Zwitserloot]

Nope, we need resolution before we can build @Mixin and @Delegate, and
we're not quite there yet.

[Rabea Gransberger]

Do you have a timetable as to when the @Delegate annotation will be
integrated in lombok?

I've been playing around with the lombok code to implement it by
myself, but as you mentioned it's not as easy as I thought at first.
The method code is generated for some easy cases, but not visible in
the eclipse outline.

[Reinier Zwitserloot]

Well, resolution is required. David's reports on his progress usually indicates it's not as complicated as we first thought, but from time to time weird cases pop up, especially in eclipse. The biggest issue at hand is that we just don't understand how eclipse's lifecycle works for parsing and compiling, so while we could slap something together and pray that it works, that's not the route we decided to take. We're working on three different things right now:

 1. A mechanism to allow writing just 1 transformer against a *much* nicer API than either javac's JCTree or eclipse's org.eclipse.jdt.internal, which will then work in all target platforms.

 2. A solution to fix the various things that lombok usually breaks in your IDE when lombok annotations are used, such as many refactor scripts.

 3. A way to add more features to java than just annotation-powered stuff, such as long strings, regexp literals, possibly closures, and more. This would also help for mixins; you'd be able to write "public class Foo mixin Bar" instead of "@Mixin(Bar.class) public class Foo" which doesn't really feel right; you don't write: "@Extends(AbstractList.class) public class Mylist" either in java today.

It was a tough choice as resolution will probably lead to more direct results in the short term, but our progress was too frustrating (basically, it consisted of trying something crazy, getting some promising initial results, but it never came together. We'd have to add something in one place, and that would break something on another place).

--Reinier Zwitserloot

--
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