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

class AddressBookEntry

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.

named parameters everywhere

the proposal is that for functions defined inside groovy or where the debug information is availlable can be called with the map construct to provide named parameter calling everywhere 

this feature would largely improve general readability of code and imho very often enough information should be availlable to perform the matching (certainly for groovy functions, very often for java binaries with appropriate debug information)

smarter nulls

should print "hello" iso "hellonull"

variable constraints

Keep dynamic typing while adding real type safety with constraints that all must be true

  • No labels