Feature Wish List

...

• More Enumerable methods for lists, arrays and maps (like map, pluck, invoke, ...)

• Make logical operators (||, &&...) return the value instead of the boolean equivalent
  eg.

  Code Block
  def x = '' || 'test' assert x == 'test' def x = null || 15 assert x == 15

• Make map creation more versatile.  Add constructors that allow creation of a map from 2 collections "HashMap(keys, values)" or a list of entries "HashMap(itemlist)".
  
• Make a list and create an auto mapping:

          eg.

//Today:
def list = ["key":"value", 1:1, 2:2, "noAuto":"noAuto"]
print(list[1]) // will print 1
//Would like to have:


def autoMapList = ["key":"value", 1, 2, "auto"]
print(autoMapList[1]) // will print 1

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

  Code Block
  //Today: def mytest { return [1,2] } c = mytest() a = c[0] b = c[1] wanted behavior: def mytest { return 1,2 } a,b = mytest()

...

Groovy 1.0 already has the method reference operator:

class X {
   def doSomething() { println "hello" }
}

def obj = new X()

def methRef = obj.&doSomething
methRef()

...

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:

class AddressBookEntry {
     Address home
     Address work
     String name

     static embedded = [ &@home, &@work ]
}

...

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 

void helloworld(name, title) {println "hello $title $name"}
can be called as
helloworld( title:"mr.", name:"koen" )

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

def hello = "hello"
def test = null
println "$hello$test"

...

Keep dynamic typing while adding real type safety with constraints on variables that all must be true.  Though not all these constraints are actually useful they are there for illustrative purposes.

percent : as Integer, >= 0, <= 100
total : != 0
...
percent = num/total

...

 Decoupling of static and instance methods

Also taken from the Scala programming language. It doesn't have static methods. All the static methods should be placed in a singleton. Static members are not a part of instance variables, so you shouldn't have to declare them in the same class.

...

Could be just like in annonymous types in C#. For example:

def foo = new (prop:"value")
foo.bar = "bar"

...

There is already quite good support for user-defined numeric data (e.g. classes that act like numeric data in expressions) using the current support for operator overloading.  But if one needs to define a class that operates in expressions like a Boolean, it can't be done.  The following changes would make this possible and these seem consistent with the overall idea and design of Groovy:

1. Enable operator overloading for logical AND, logical OR, logical NOT. For logical AND and logical OR, the deferred evaluation of the right operand can be maintained by passing a Closure to the method.  The signatures might be something like this:

   Code Block
   Boolean land(Closure)   Boolean lor(Closure) Boolean lnot()

2. Enable assignment operator overloading.  This is needed to allow a semantic like

   Code Block
   MyBooleanClass bool = true

   Note that overriding the assignment operator makes it significantly easier to replace numeric types too since one can handle cases like

   Code Block
   MyNumericClass num = 10

   which is not possible today.

3. Today due to "Groovy Truth" processing, any non-null object reference (that is not a Boolean) will evaluate to true.  To enable user-defined Boolean type data, Groovy Truth would need to be modified to optionally "unbox" a non-null object reference into a Boolean value if it has a booleanValue() method.  This would allow one to do something like this

   Code Block
   MyBooleanType bool = something(); if bool || somethingElse() { ... }

   In such a case, the bool instance can be either false or true and can be directly used for control flow and other operations that normally expect a Boolean.
   With these changes, user-defined boolean replacement classes would get first-class support in the language.

 Smalltalk-like syntax for methods

...

def print: aCustomer as Customer  on: aStream as FileStream {
...
}

use example :

def aCustomer = new Customer();
WriteStream aStream = new FileStream();
print:aCustomer on: aStream ;

Expect for Groovy

What is expect?

Expect has been already ported to other languages:

Expect for Perl

Why can't we have it built in?

My proposal:

Expect for Groovy 

Automatic constructor for immutable Groovy Beans

...