groovy/groovy-core — pull request #495 by ddimtirov (2014-07-24 01:53:54+00:00)
Title: Differences in Strings and Character literals

A first batch of proposed changes for the Groovy/Java differences page.

Looking at my notes, many of the things I have are not so much about differences between the languages, but about counterintuitive behavior from the point of view of a Java developer learning Groovy. I am not sure whether they belong in this page or a separate page.

Here is a summary, please let me know what you think:

````
Characters
- single quotes define Strings (double quotes are for GStrings)
- implicitly cast 1 char String and GString to character
- the Groovy language does not support primitive char variables
- primitive and wrapper char boxing/unboxing works with 1-char strings
- casting multi-char string with the 'as' operator returns first char
- casting multi-char string with the C-cast operator fails

--- --- --- --- ---

Numbers
- int and long literals
- integer overflow on addition, subtraction and multiplication
- division operator promotes int types to BigDecimal
- integer division

Strings
- introducing GString interpolation
- delayed expansion of interpolated expressions
- GStrings are usually equal to equivalent Strings, but hash code is different
- enclosing scope from another function
- multi-line strings
- slashy strings

Regexes
- full and partial matching operators
- partial matching returns a java.util.regex.Matcher
- accessing matches
- slicing matches
- accessing matched groups by index
- accessing matched groups by iteration
- using slashy strings for regexes

Collections
- determining map's class (MOP property redefinition)
- unquoted keys in maps are treated as strings (unless ints)
- multi-word keys need quotes, expressions need parens)
- dynamic dispatch for List.remove(int)
- sort() and unique() chained API's are mutating the subject
- use defensive copies
- flatten and reverse are functional

Groovy Truth

Signatures
- varargs and named params
- empty varargs is empty list, empty named params is null
- can be changed with explicit default value
- parens can be skipped when we don't use the function's return value
- but not when the only argument is a list literal (parse ambiguous with indexing)
- trailing closures can be behind parens
- but not for constructors (ambiguous with anonymous subclass)
- call println without parens
- except when argument is starting with parenthesized expression
````