Message-ID: <443355656.277.1429328478163.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_276_1866409055.1429328478163" ------=_Part_276_1866409055.1429328478163 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Please use this page to document all the ideas and wishes you'd = like to see in Groovy.
Objective: get rid of a lot of if then else statements; eliminate unnece= ssary syntax; no impact on "java-like" groovy code.
Here the '->' form implies 'return' instead of 'break' (same result a= t this level)
Here you can see the special "case" is executed when the list = size is less than 2, otherwise it looks like a normal closure.
The above proposal does not break any existing code, does not add any ke= ywords, does not break compatibility with java ("paste java in to groo= vy and it work", etc).
The multi-parameter switch statement and '->' in a switch so it has a= result is where the core of the work would be. The 'case' statement on a c= losure definition for pattern matching like capability is just syntactical = sugar.
--krsmes (Apr 2010)
e.g. [null,'Hello','world',null].= join(' ') will produce 'Hello world'
Make logical operators (||, &&...) =
return the value instead of the boolean equivalent
would like methods to return more than one return value (a la ruby)<= /p>
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 obj= ect for any object property, and be able to get and set the property via th= e reference, and get the original property name and owning bean:
This would be useful in Grails and othe= r apps that need the user to specify in their code a reference to another p= ropery, for example in GORM declaring the list of "embedded" prop= erties:
Property access in groovy is not problematic using GPath or subscript op= erator 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 al= low the compiler to ensure that "home" and "work" do ex= ist as declared properties on the class or its ancestors, and hence fail fa= st.
the proposal is that for functions defined inside groovy or where the de= bug information is availlable can be called with the map construct to provi= de named parameter calling everywhere
this feature would largely improve gene= ral readability of code and imho very often enough information should be av= aillable to perform the matching (certainly for groovy functions, very ofte= n for java binaries with appropriate debug information)
should print "hello" iso &quo= t;hellonull"
Keep dynamic typing while adding real type safety with constraints on va= riables that all must be true. Though not all these constraints are a= ctually useful they are there for illustrative purposes.
The programming language Scala has built-in support for XML. You= can create something like this (taken from the Scala overview document):= p>
Also taken from the Scala programming language. It doesn't have = static methods. All the static methods should be placed in a singleton. Sta= tic 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:
First Class Support for User-Defined Boolean Types
There is already quite good support for user-defined numeric data (e.g. = classes that act like numeric data in expressions) using the current suppor= t for operator overloading. But if one needs to define a class that o= perates in expressions like a Boolean, it can't be done. The followin= g changes would make this possible and these seem consistent with the overa= ll idea and design of Groovy:
Enable operator overloading for logical AND, logical OR, logical NOT= . For logical AND and logical OR, the deferred evaluation of the right oper= and can be maintained by passing a Closure to the method. The signatu= res might be something like this:
Enable assignment operator overloading. This is needed to allo= w a semantic like
Note that overriding the assignment operator makes it significantl= y easier to replace numeric types too since one can handle cases like
which is not possible today.
Today due to "Groovy Truth" processing, any non-null objec= t 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 o= ptionally "unbox" a non-null object reference into a Boolean valu= e if it has a booleanValue() method. This would allow one to do somet= hing like this
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 ex=
pect a Boolean.
With these changes, use= r-defined boolean replacement classes would get first-class support in the = language.
I've seen that in Groovy 1.5 it was possible to avoid using parent= hesis when calling a method. It was made to simplify the reading in a more = natural way...
Nevertheless I'm not sure that the goal is today reached... The gr= oovy syntax was primarly settled to make the step from Java easier fo= r java coders...Along the versions, some syntactic sugar was added to fulfi= ll new needs...to reach the point where going from jav to groovy is not so = straightforward... Personnaly it is not an issue, but I would like to point= out that if we differ more and more from java, why not adopting a syntax w= hich is more accurate and simpler?
Personnaly, I find the Smalltalk syntax simpler and more elegant... I th= ink that we could add some syntactic "tournures" of Smalltalk in = Groovy 2.0, especially for defining new methods....
definition example :
use example :
Expect has been already ported to other languages:
Why can't we have it built in?
Automatically create a constructor for all final properties of a Groovy = Bean.
There should be no setters generated, and not be possible to change the = values of id or name after object creation.
It would be even better if you could use named parameters to the constru= ctor as well: