Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 31 Next »

Please use this page to document all the ideas and wishes you'd like to see in Groovy.

  • Support standard for statement. (Note: supported by the JSR grammar.)
    e.g. for (int i = 0; i < 5; ++i)
    {... I don't know whether the standard for statement is still not implemented till beta-10, or Groovy will not support it in 1.0 release.
  • New function for integers to reverse bits.
  • Concatenate string with null object.  'Test'+null will produce 'Test'.
  • Function/Global method 'NVL'. This method avoid null/empty string value of object. E.g. NVL(null,'Test')='Test' and NVL('','Test')='Test'
  • Joining of list without null elements.

         e.g. [null,'Hello','world',null].join(' ') will produce 'Hello world'

  •  Simple and Robust way of executing external processes instead of using ProcessBuilder. Make the convenient string.execute() handle blocked IO streams / threading so users are not required know or understand about ProcessBuilder
  • Import Static.  Just like in Java 1.5.
  • More Enumerable methods for lists, arrays and maps (like map, pluck, invoke, ...)
  • Make logical operators (||, &&...) return the value instead of the boolean equivalent
  • Make a list and create an auto mapping:


  • would like methods to return more than one return value (a la ruby)

Property reference operator

Groovy 1.0 already has the method reference operator:

However we do not have anything similar for properties. i.e. we should be able to get a reference to a wrapper object for any object property, and be able to get and set the property via the reference, and get the original property name and owning bean:

This would be useful in Grails and other apps that need the user to specify in their code a reference to another propery, for example in GORM declaring the list of "embedded" properties:

Property access in groovy is not problematic using GPath or subscript operator anyway, so this may not seem so useful. However if we could get some compile-time checking of the validity of the property that would be a nice win. Perhaps combining with the @ operator:

Altho a tad heiroglyphic, this would allow the compiler to ensure that "home" and "work" do exist as declared properties on the class or its ancestors, and hence fail fast.

  • No labels