[jira] [Commented] (GROOVY-8992) [GEP]Polish the generics type syntax for closure
[
https://issues.apache.org/jira/browse/GROOVY-8992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782735#comment-17782735
]
Eric Milles commented on GROOVY-8992:
-
There was discussion in another ticket to add the {{TYPE_USE}} target to
{{@ClosureParams}} and {{@DelegatesTo}} so the return type of an annotation
attribute method could be tagged. I think the {{METHOD}} target would allow
this as well -- but would be wider than the intended use case. A type
annotation would allow for a representation that Java can understand.
I still feel that this custom syntax is not preferred over enhancements to
ClosureParams and DelegatesTo. For example, there is no support for
disambiguation in the syntax-based approach. {{each(Map map,
@ClosureParams(MapEntryOrKeyValue.class) Closure consumer)}} is a quick example
of this added flexibility.
> [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
>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
> 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 V>
> {code}
> ② √ Suggestions of [~blackdrag] are much groovier for all cases:
> {code:java}
> Closure
> {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}
> ④ ? [~emge] proposed the simplified version of ③.
> {code:java}
> Closure
> {code}
> h2. 3. Benefits
> ① The new syntax of generics type for closure is much more concise and
> readable:
> {code:java}
> Closure
> {code}
> {code:java}
> Closure // qualified name is not necessary if using imports
> {code}
> *VS*
> {code:java}
> @ClosureParams(value=SimpleType.class, options="groovy.sql.Sql") Closure
> {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}} 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}}
> will be transformed to
> {{@ClosureParams(value=SimpleType.class, options="groovy.sql.Sql")
> Closure}}
> 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
(v8.20.10#820010)
[jira] [Commented] (GROOVY-8992) [GEP]Polish the generics type syntax for closure
[
https://issues.apache.org/jira/browse/GROOVY-8992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770451#comment-16770451
]
Eric Milles commented on GROOVY-8992:
-
How would you represent this to Java? Closure is in keeping with Java's
notion of generics. And the type parameter V is used in method signatures
within Closure. If you had Closure<():R1; (X):R2; (Y, Z):R3>, how would R1, R2
and R3 be used throughout the class definition?
I disagree on the point of simpler IDE support. Eclipse and IntelliJ have
already completed support for @ClosureParams and @DelegatesTo. This would be
new development and may need to be conditionally enabled, since the syntax will
not be in all Groovy versions.
> [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
> 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 V>
> {code}
> ② √ Suggestions of [~blackdrag] are much groovier for all cases:
> {code:java}
> Closure
> {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}
> ④ ? [~emge] proposed the simplified version of ③.
> {code:java}
> Closure
> {code}
> h2. 3. Benefits
> ① The new syntax of generics type for closure is much more concise and
> readable:
> {code:java}
> Closure
> {code}
> {code:java}
> Closure // qualified name is not necessary if using imports
> {code}
> *VS*
> {code:java}
> @ClosureParams(value=SimpleType.class, options="groovy.sql.Sql") Closure
> {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}} 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}}
> will be transformed to
> {{@ClosureParams(value=SimpleType.class, options="groovy.sql.Sql")
> Closure}}
> 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)
[jira] [Commented] (GROOVY-8992) [GEP]Polish the generics type syntax for closure
[
https://issues.apache.org/jira/browse/GROOVY-8992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770174#comment-16770174
]
mgroovy commented on GROOVY-8992:
-
* Alternative suggestion:
{code}Closure{code}
* This would put the return type first, which
** is aligned with existing method argument syntax
** often is the most important information imho
** would be more in line with the current Closure logic
> [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
> 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 V>
> {code}
> ② √ Suggestions of [~blackdrag] are much groovier for all cases:
> {code:java}
> Closure
> {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
> {code}
> {code:java}
> Closure // qualified name is not necessary if using imports
> {code}
> *VS*
> {code:java}
> @ClosureParams(value=SimpleType.class, options="groovy.sql.Sql") Closure
> {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}} 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}}
> will be transformed to
> {{@ClosureParams(value=SimpleType.class, options="groovy.sql.Sql")
> Closure}}
> 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)
[jira] [Commented] (GROOVY-8992) [GEP]Polish the generics type syntax for closure
[
https://issues.apache.org/jira/browse/GROOVY-8992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
> 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 V>
> {code}
> ② √ Suggestions of [~blackdrag] are much groovier for all cases:
> {code:java}
> Closure
> {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
> {code}
> {code:java}
> Closure // qualified name is not necessary if using imports
> {code}
> *VS*
> {code:java}
> @ClosureParams(value=SimpleType.class, options="groovy.sql.Sql") Closure
> {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}} 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}}
> will be transformed to
> {{@ClosureParams(value=SimpleType.class, options="groovy.sql.Sql")
> Closure}}
> 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)
[jira] [Commented] (GROOVY-8992) [GEP]Polish the generics type syntax for closure
[
https://issues.apache.org/jira/browse/GROOVY-8992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770141#comment-16770141
]
Daniel Sun commented on GROOVY-8992:
I inclined to use \{{;}} instead of \{{|}}, because \{{|}} is reserved for
Union Type.
> [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
> 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 V>
> {code}
> ② √ Suggestions of [~blackdrag] are much groovier for all cases:
> {code:java}
> Closure
> {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}
> @ClosureParams(value=SimpleType.class, options="groovy.sql.Sql") Closure
> {code}
> *VS*
> {code:java}
> Closure
> {code}
> {code:java}
> Closure // qualified name is not necessary if using imports
> {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}} 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}}
> will be transformed to
> {{@ClosureParams(value=SimpleType.class, options="groovy.sql.Sql")
> Closure}}
> 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)
[jira] [Commented] (GROOVY-8992) [GEP]Polish the generics type syntax for closure
[
https://issues.apache.org/jira/browse/GROOVY-8992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770140#comment-16770140
]
Daniel Sun commented on GROOVY-8992:
Will this also be supported:
{\{Closure<(Sql) : V>}}
Yep. It's similar to the syntax of lambda parameter list ;)
> [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
> 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 V>
> {code}
> ② √ Suggestions of [~blackdrag] are much groovier for all cases:
> {code:java}
> Closure
> {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}
> @ClosureParams(value=SimpleType.class, options="groovy.sql.Sql") Closure
> {code}
> *VS*
> {code:java}
> Closure
> {code}
> {code:java}
> Closure // qualified name is not necessary if using imports
> {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}} 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}}
> will be transformed to
> {{@ClosureParams(value=SimpleType.class, options="groovy.sql.Sql")
> Closure}}
> 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)
[jira] [Commented] (GROOVY-8992) [GEP]Polish the generics type syntax for closure
[
https://issues.apache.org/jira/browse/GROOVY-8992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770139#comment-16770139
]
mgroovy commented on GROOVY-8992:
-
* What about seperating the different argument varieties with | instead of ; ?
* Based on that they are sort-of aggregated types:
{code}Closure<():R1|(X):R2|(Y, Z):R3>{code}
* Or more compact/groovy:
{code}Closure{code}
> [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
> 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 V>
> {code}
> ② √ Suggestions of [~blackdrag] are much groovier for all cases:
> {code:java}
> Closure
> {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}
> @ClosureParams(value=SimpleType.class, options="groovy.sql.Sql") Closure
> {code}
> *VS*
> {code:java}
> Closure
> {code}
> {code:java}
> Closure // qualified name is not necessary if using imports
> {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}} 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}}
> will be transformed to
> {{@ClosureParams(value=SimpleType.class, options="groovy.sql.Sql")
> Closure}}
> 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)
[jira] [Commented] (GROOVY-8992) [GEP]Polish the generics type syntax for closure
[
https://issues.apache.org/jira/browse/GROOVY-8992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770137#comment-16770137
]
mgroovy commented on GROOVY-8992:
-
Will this also be supported:
Closure<(Sql) : V>
? It seems a good idea for consistency reasons...
> [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
> 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 V>
> {code}
> ② √ Suggestions of [~blackdrag] are much groovier for all cases:
> {code:java}
> Closure
> {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}
> @ClosureParams(value=SimpleType.class, options="groovy.sql.Sql") Closure
> {code}
> *VS*
> {code:java}
> Closure
> {code}
> {code:java}
> Closure // qualified name is not necessary if using imports
> {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}} 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}}
> will be transformed to
> {{@ClosureParams(value=SimpleType.class, options="groovy.sql.Sql")
> Closure}}
> 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)
