groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "mgroovy (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GROOVY-8992) [GEP]Polish the generics type syntax for closure
Date Sat, 16 Feb 2019 18:35:00 GMT

    [ https://issues.apache.org/jira/browse/GROOVY-8992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16770168#comment-16770168
] 

mgroovy commented on GROOVY-8992:
---------------------------------

* That's why I suggested it: The result of the closure call is either R1, R2 or R3 (depending
on parameters passed), so you can read it as "or", or as a sort-of a union of the three types.
 * It also would have the advantage of allowing a more concise syntax, since the vertical
bar seperates more clearly than the semicolon, so you don't need the brackets.

> [GEP]Polish the generics type syntax for closure
> ------------------------------------------------
>
>                 Key: GROOVY-8992
>                 URL: https://issues.apache.org/jira/browse/GROOVY-8992
>             Project: Groovy
>          Issue Type: Improvement
>            Reporter: Daniel Sun
>            Assignee: Daniel Sun
>            Priority: Major
>
> h2. 1. Background
> Currently the syntax specifying the generics type for closure is quite verbose and not
type safe, e.g.
> {code:java}
> @ClosureParams(value=SimpleType.class, options="groovy.sql.Sql") Closure<V> closure
> {code}
> h2. 2. Solutions
> ① ×  I propose to make the above code groovier, but the proposed "arrow syntax making
it hard to read, in particular when the argument types have generics themselves" reminded
by [~melix], e.g.
> {code:java}
> Closure<groovy.sql.Sql -> V>
> {code}
> ② √  Suggestions of [~blackdrag] are much groovier for all cases:
> {code:java}
> Closure<groovy.sql.Sql : V>
> {code}
> ③ √  In the meanwhile, [~blackdrag] proposed other variants of the generics type
syntax for closure to handle "polymorphic closures (aka closures which accept different kind
of arguments)" reminded by [~melix]
> {code:java}
> Closure<():R1; (X):R2; (Y, Z):R3>
> {code}
> h2. 3. Benefits
> ① The new syntax of generics type for closure is much more concise and readable:
> {code:java}
> Closure<groovy.sql.Sql:V>
> {code}
> {code:java}
> Closure<Sql:V> // qualified name is not necessary if using imports
> {code}
> *VS*
> {code:java}
> @ClosureParams(value=SimpleType.class, options="groovy.sql.Sql") Closure<V>
> {code}
> ② Type checking can be completed in the compilation time, so we can find errors in
time, e.g. {{@ClosureParams(... options="groovy.sql.SqlAbc")}} of annotation specifies the
type with string literal, but the type does not exist, so we can not the error in the compilation
time. On the contrast, {{Closure<groovy.sql.SqlAbc:V>}} can make compiler help us find
type errors in the compilation time.
>  ③ Better IDE support because of using the types instead of string literals for types
> h2. 4. Rationale
> In order to keep "consistency between using annotations and a type-checking only feature"
reminded by [~melix], I propose to transform the groovier code to the original code when compiling,
e.g.
>  {{Closure<groovy.sql.Sql:V>}}
>  will be transformed to
>  {{@ClosureParams(value=SimpleType.class, options="groovy.sql.Sql") Closure<V>}}
> h2. 5. Discussions in the dev mailing list
> [http://groovy.329449.n5.nabble.com/About-polish-the-generics-type-syntax-for-closure-tt5756586.html]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message