You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@groovy.apache.org by "Daniel Sun (JIRA)" <ji...@apache.org> on 2019/02/16 15:29:00 UTC
[jira] [Updated] (GROOVY-8992) Polish the generics type syntax for
closure
[ https://issues.apache.org/jira/browse/GROOVY-8992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Sun updated GROOVY-8992:
-------------------------------
Description:
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 make the above code groovier, e.g.
{code:java}
Closure<groovy.sql.Sql -> V>
{code}
② Suggestions of [~blackdrag] is 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:
*Currently*
{{@ClosureParams(value=SimpleType.class, options="groovy.sql.Sql") Closure<V>}}
*Proposed*
{{Closure<groovy.sql.Sql:V>}}
{{Closure<Sql:V> // qualified name is not necessary if using imports}}
② 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, 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]
was:
h2. 1. Background
Currently the syntax specifying the generics type for closure is quite verbose... e.g.
{code:java}
@ClosureParams(value=SimpleType.class, options="groovy.sql.Sql") Closure<V> closure
{code}
h2. 2. Solutions
① I propose make the above code groovier, e.g.
{code:java}
Closure<groovy.sql.Sql -> V>
{code}
② Suggestions of [~blackdrag] is 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:
*Currently*
{{@ClosureParams(value=SimpleType.class, options="groovy.sql.Sql") Closure<V>}}
*Proposed*
{{Closure<groovy.sql.Sql:V>}}
{{Closure<Sql:V> // qualified name is not necessary if using imports}}
② 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, 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
> 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 make the above code groovier, e.g.
> {code:java}
> Closure<groovy.sql.Sql -> V>
> {code}
> ② Suggestions of [~blackdrag] is 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:
> *Currently*
> {{@ClosureParams(value=SimpleType.class, options="groovy.sql.Sql") Closure<V>}}
> *Proposed*
> {{Closure<groovy.sql.Sql:V>}}
> {{Closure<Sql:V> // qualified name is not necessary if using imports}}
> ② 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, 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)