Hi devs, Project Lombok sounds cool: http://projectlombok.org/ WDYT?

Few words from outside: using 'not-plain' java for compilation and require download extra tool on top of Eclipse, will prevent outside developers (especially vi lowers) from touching xwiki code.

On Mon, Nov 23, 2009 at 9:32 PM, Asiri Rathnayake < asiri.rathnayake(a)gmail.com&gt; wrote: about those Isn't the automatic creation of getters and setters one of the features of groovy, which is already tightly integrated into Xwiki? Looking at lombok feature list, every single feature is already provided by Groovy, much more elegantly, and already part of Xwiki, except for perhaps the @Synchronized, which is accomplished far more elegantly in clojure ( http://blip.tv/file/812787/ ) http://projectlombok.org/features/index.html http://projectlombok.org/features/ToString.html>No http://projectlombok.org/features/EqualsAndHashCode.html>Equality all http://projectlombok.org/features/Cleanup.html>Automatic http://projectlombok.org/features/SneakyThrows.html>To Fabio Mancinelli said: W/r/t adding macros or making "small custom languages" -- groovy has it's meta-object protocol, and then there's the even nicer way of doing things -- clojure -- it's silly to try to emulate "lisp macros in java" because the syntax is all wrong to begin with. There's solid theoretical reasons for lisp looking like it does (e.g. Church's lambda calculus and Quine's set theory<http://www.rbjones.com/rbjpub/logic/cl/index.htm>)m>), and the language-power you get from treating programs as 1st-class data and vice-versa (where the first-classness, and the ability to create closures that work transparently and correctly is the key to it all). IMHO, adding an IDE to make Java look more Lispy is an odd use of precious resources. Why not make java look more lispy directly? http://clojure.org/ -- a project with far more buzz and traction than lombok, cool-looking-as-it-is; Lombok would end up "microsofting" development efforts by forcing a single solution on what should be an open-market. IDE-wars are even worse than language wars, IMHO, which is why I'd hope effort is put into generally-useful "platform" solutions that would provide equal benefit to all IDE users as well as regular Xwiki web-users. Note that both clojure and groovy have IDE support in eclipse. Should language level extensions be necessary, groovy's Meta-object protocol support should obviate the need for further Xwiki extensions. See chapters 12 and onward in http://www.pragprog.com/titles/vslg/programming-groovy Part 3: “MOPping Groovy” Metaprogramming is one of the biggest benefits of dynamic languages and Groovy; it has the ability to inspect classes at runtime and dynam- ically dispatch method calls. You’ll explore Groovy’s support for meta- programming in Chapter 12, Exploring Meta-Object Protocol (MOP), on page 186, beginning with the fundamentals of how Groovy handles method calls to Groovy objects and Java objects. Groovy allows you to perform AOP-like method interceptions using GroovyInterceptable and ExpandoMetaClass, as you’ll see in Chapter 13, Intercepting Methods Using MOP, on page 196. In Chapter 14, MOP Method Injection and Synthesis, on page 204, you’ll dive into Groovy metaprogramming capabilities that allow you to inject and synthesize methods at runtime. In Chapter 15, MOPping Up, on page 226, you will learn how to syn- thesize classes dynamically, how to use metaprogramming to delegate method calls, and how to choose between different metaprogramming techniques you’ve learned in the previous three chapters. Unit testing is not a luxury or a “if-we-have-time” practice in Groovy. The dynamic nature of Groovy requires unit testing, and fortunately, at the same time, it facilitates writing tests and creating mock objects, as you’ll learn in Chapter 16, Unit Testing and Mocking, on page 236. You will learn techniques that will help you use Groovy to unit test your Java code and Groovy code. Groovy builders are specialized classes that help you build internal DSLs for a nested hierarchy. You can learn how to use them and to create your own builders in Chapter 17, Groovy Builders, on page 262. You can apply Groovy’s metaprogramming capabilities to build internal DSLs using the techniques you’ll learn in Chapter 18, Creating DSLs in Groovy, on page 279. You’ll start by learning about DSLs, including their characteristics, and quickly jump in to build them in Groovy. -- Niels. http://nielsmayer.com _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs