Message-ID: <550384107.25923.1394293645895.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_25922_1573303774.1394293645895" ------=_Part_25922_1573303774.1394293645895 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Groovy reduces typing to a second-class citizen, and I think it = is very reasonable to use that as an excuse to eliminate the traditional ty= pe-cast syntax. In a dynamically-typed language, it is very difficult to kn= ow what is a type and what is a variable, so any syntax that allows one to = be mistaken for the other is bad for both readability and parsing.
I propose we add "as" as an operator which will be used in pla= ce of the traditional type-cast operator, and which can be overloaded on th= e class for doing things like automatic type conversions.
In the above example, InputStream would define an asReader() method, whi= ch would be used by the compiler to do the type conversion. The compiler it= self does the type cast, of course.
As "as" is an infix operator that has specific operand require= ments, we eliminate the ambiquities of what is a type and what isn't. Consi= der the following code:
Whether that is a type cast or an addition is less-than-trivial to figur= e out during compilation. Further, if Test is a class in the local package,= it might be totally ambiguous to the casual reader, too.
The same code with the new syntax is much more obvious:
The problem gets worse if the class name starts with a lower-case letter= and proper scoping is in effect:
Is that an addition of two variables, a type cast, or the addition of th= e result of the delegate's getTest() accessor and a? It is utterly= impossible to say until runtime, if proper scoping is in effect.<= /p>
For complex cases, "as" is mainly neutral on readability (it r= educes parenthesis counts, but calls less attention to the purpose of the c= ode). Compare:
A further benefit of this change is that if we allow class names to be o= verridden by local variables, type-casting will still be possible:
Maybe not advisable, but all unambiguous.
From the viewpoint of preserving optionals, changing to "as" i= s important as it eliminates an overload for parenthesis. As optional paren= thesis on method calls are considered by many to be an important feature of= the language, eliminating ambiguity is important. Consider:
The parser is entirely at a loss with these, and will usually guess wron= g. This then means rewriting of the AST by later phases, once the problem h= as been identified.
That said, we still can't eliminate:
but some reduction in ambiguity is better than none.
=E2=80=93 Chris Poirier.