[jira] [Commented] (GROOVY-9649) left-open and full-open ranges
[
https://issues.apache.org/jira/browse/GROOVY-9649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318655#comment-17318655
]
Daniel Sun commented on GROOVY-9649:
+1
> left-open and full-open ranges
> --
>
> Key: GROOVY-9649
> URL: https://issues.apache.org/jira/browse/GROOVY-9649
> Project: Groovy
> Issue Type: New Feature
>Reporter: Björn Kautler
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> I found there are right-open ranges like {{1..<5}} for {{[1, 2, 3, 4]}}, but
> no left-open ranges and full-open ranges.
> I'd like to suggest adding those, e. g. {{1<..5}} for {{[2, 3, 4, 5]}} and
> {{1<..<5}} for {{[2, 3, 4]}}.
> For decimals it would be similar, just omitting the lower bound if it matches.
> Currently
> {{3.5..<5.7}} gives {{[3.5, 4.5, 5.5]}}
> {{3.5..<5.5}} gives {{[3.5, 4.5]}}
> So with my suggestion it would then probably be
> {{3.5<..5.5}} gives {{[4.5, 5.5]}}
> {{3.5<..<5.7}} gives {{[4.5, 5.5]}}
> {{3.5<..<5.5}} gives {{[4.5]}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GROOVY-10030) Bump asciidoctor versions
[ https://issues.apache.org/jira/browse/GROOVY-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-10030. Fix Version/s: 4.0.0-alpha-3 Resolution: Fixed > Bump asciidoctor versions > - > > Key: GROOVY-10030 > URL: https://issues.apache.org/jira/browse/GROOVY-10030 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 4.0.0-alpha-3 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GROOVY-10030) Bump asciidoctor versions
Paul King created GROOVY-10030: -- Summary: Bump asciidoctor versions Key: GROOVY-10030 URL: https://issues.apache.org/jira/browse/GROOVY-10030 Project: Groovy Issue Type: Dependency upgrade Reporter: Paul King Assignee: Paul King -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-10024) Dollar slashy /$ string ending in backslash "breaks" the parser
[
https://issues.apache.org/jira/browse/GROOVY-10024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-10024:
---
Priority: Critical (was: Blocker)
> Dollar slashy /$ string ending in backslash "breaks" the parser
> ---
>
> Key: GROOVY-10024
> URL: https://issues.apache.org/jira/browse/GROOVY-10024
> Project: Groovy
> Issue Type: Bug
> Components: parser
>Affects Versions: 3.0.7
>Reporter: Przemek Bielicki
>Assignee: Paul King
>Priority: Critical
> Fix For: 3.0.8, 4.0.0-alpha-3
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The minimal reproducer is the following:
> {code:groovy}
> def s1 = $/Failing string\\/$
> def s2 = $/Will not be parsed as a new line/$
> println s1
> {code}
> A line starting with {{def s2}} will be "swallowed". The result of it is:
> {code:java}
> Failing string\/$
> def s2 = /Will not be parsed as a new line
> {code}
> It looks like {{\/$}} is ignored by the parser and it's continuing until the
> next "valid" occurence of {{/$}}.
> It worked in 2.x
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-10011) Combining flow typing and type argument inference does not work as expected
[
https://issues.apache.org/jira/browse/GROOVY-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-10011:
---
Fix Version/s: 3.0.8
> Combining flow typing and type argument inference does not work as expected
> ---
>
> Key: GROOVY-10011
> URL: https://issues.apache.org/jira/browse/GROOVY-10011
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Reporter: Thodoris Sotiropoulos
>Assignee: Eric Milles
>Priority: Major
> Fix For: 3.0.8, 4.0.0-alpha-3
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I have the following program
> {code:java}
> class A {
> T f;
> public A(T f) {
> this.f = f;
> }
> }
> class Foo {}
> class Bar extends Foo {}
> public class Main {
> public static void bar(Foo x) {
> if (x instanceof Bar) {
> A a = new A<>(x)
> }
> }
> }
> {code}
> h3. Actual Behavior
> {code:java}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> test.groovy: 15: [Static type checking] - Incompatible generic argument
> types. Cannot assign A to: A
> @ line 15, column 18.
> A a = new A<>(x)
> ^1 error
> {code}
> h3. Expected Behavior
> Compile successfully
>
> Tested against
> https://github.com/apache/groovy/commit/359be2b662be646d2d59db8b999412691891231d
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9996) Cannot infer correct type argument when using subtyping
[
https://issues.apache.org/jira/browse/GROOVY-9996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-9996:
--
Fix Version/s: 3.0.8
> Cannot infer correct type argument when using subtyping
> ---
>
> Key: GROOVY-9996
> URL: https://issues.apache.org/jira/browse/GROOVY-9996
> Project: Groovy
> Issue Type: Bug
>Reporter: Stefanos Chaliasos
>Assignee: Eric Milles
>Priority: Major
> Fix For: 3.0.8, 4.0.0-alpha-3
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I have the following Groovy program.
> {code:groovy}
> @groovy.transform.CompileStatic
> public class Main {
> public static void main(String[] args) {
> Foo foo = new Bar()
> def x = new A<>(foo)
> bar(x)
> }
> public static void bar(A f) {}
> }
> class A {
> T f;
> public A(T f) {
> this.f = f;
> }
> }
> class Foo {}
> class Bar extends Foo {}
> {code}
> h2. Actual Behavior
> The program does not compile, and I get the following error.
> {code:java}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> Main.groovy: 6: [Static type checking] - Cannot call Main#bar(A ) with
> arguments [A ]
> @ line 6, column 5.
>bar(x)
>^
> 1 error
> {code}
> h2. Expected Behavior
> Compile successfully.
> h2. Affected Version
> This should be a regression. The program compiles with 3.0.7 and
> 4.0.0-alpha-2, but fails with the compiler from Master (commit:
> e69c874e1a6a3cdeb236bad6a6faa061a30c88ca).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-10024) Dollar slashy /$ string ending in backslash "breaks" the parser
[
https://issues.apache.org/jira/browse/GROOVY-10024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-10024:
-
Fix Version/s: 3.0.8
> Dollar slashy /$ string ending in backslash "breaks" the parser
> ---
>
> Key: GROOVY-10024
> URL: https://issues.apache.org/jira/browse/GROOVY-10024
> Project: Groovy
> Issue Type: Bug
> Components: parser
>Affects Versions: 3.0.7
>Reporter: Przemek Bielicki
>Assignee: Paul King
>Priority: Blocker
> Fix For: 3.0.8, 4.0.0-alpha-3
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The minimal reproducer is the following:
> {code:groovy}
> def s1 = $/Failing string\\/$
> def s2 = $/Will not be parsed as a new line/$
> println s1
> {code}
> A line starting with {{def s2}} will be "swallowed". The result of it is:
> {code:java}
> Failing string\/$
> def s2 = /Will not be parsed as a new line
> {code}
> It looks like {{\/$}} is ignored by the parser and it's continuing until the
> next "valid" occurence of {{/$}}.
> It worked in 2.x
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [groovy] asfgit merged pull request #1550: GROOVY-10023: Remove BSF module from Groovy 4
asfgit merged pull request #1550: URL: https://github.com/apache/groovy/pull/1550 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] paulk-asert commented on pull request #1552: GROOVY-10024: Dollar slashy /$ string ending in backslash "breaks" th…
paulk-asert commented on pull request #1552: URL: https://github.com/apache/groovy/pull/1552#issuecomment-817205968 Proposed PR merged. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] asfgit merged pull request #1552: GROOVY-10024: Dollar slashy /$ string ending in backslash "breaks" th…
asfgit merged pull request #1552: URL: https://github.com/apache/groovy/pull/1552 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] paulk-asert commented on pull request #1547: Updates Micronaut Joint Validation to Micronaut 3.0.x branch
paulk-asert commented on pull request #1547: URL: https://github.com/apache/groovy/pull/1547#issuecomment-817206317 Merged, thanks! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] paulk-asert merged pull request #1547: Updates Micronaut Joint Validation to Micronaut 3.0.x branch
paulk-asert merged pull request #1547: URL: https://github.com/apache/groovy/pull/1547 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] asfgit closed pull request #1545: GROOVY-10011: STC: instanceof refines declared type for diamond operator
asfgit closed pull request #1545: URL: https://github.com/apache/groovy/pull/1545 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (GROOVY-10023) Remove BSF from Groovy 4
[ https://issues.apache.org/jira/browse/GROOVY-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Milles resolved GROOVY-10023. -- Fix Version/s: 4.0.0-alpha-3 Resolution: Fixed > Remove BSF from Groovy 4 > > > Key: GROOVY-10023 > URL: https://issues.apache.org/jira/browse/GROOVY-10023 > Project: Groovy > Issue Type: Task >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 4.0.0-alpha-3 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GROOVY-10011) Combining flow typing and type argument inference does not work as expected
[
https://issues.apache.org/jira/browse/GROOVY-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles resolved GROOVY-10011.
--
Fix Version/s: 4.0.0-alpha-3
Resolution: Fixed
> Combining flow typing and type argument inference does not work as expected
> ---
>
> Key: GROOVY-10011
> URL: https://issues.apache.org/jira/browse/GROOVY-10011
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Reporter: Thodoris Sotiropoulos
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0-alpha-3
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I have the following program
> {code:java}
> class A {
> T f;
> public A(T f) {
> this.f = f;
> }
> }
> class Foo {}
> class Bar extends Foo {}
> public class Main {
> public static void bar(Foo x) {
> if (x instanceof Bar) {
> A a = new A<>(x)
> }
> }
> }
> {code}
> h3. Actual Behavior
> {code:java}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> test.groovy: 15: [Static type checking] - Incompatible generic argument
> types. Cannot assign A to: A
> @ line 15, column 18.
> A a = new A<>(x)
> ^1 error
> {code}
> h3. Expected Behavior
> Compile successfully
>
> Tested against
> https://github.com/apache/groovy/commit/359be2b662be646d2d59db8b999412691891231d
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [groovy] paulk-asert commented on pull request #1545: GROOVY-10011: STC: instanceof refines declared type for diamond operator
paulk-asert commented on pull request #1545: URL: https://github.com/apache/groovy/pull/1545#issuecomment-817206775 Merged, thanks! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (GROOVY-10024) Dollar slashy /$ string ending in backslash "breaks" the parser
[
https://issues.apache.org/jira/browse/GROOVY-10024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles resolved GROOVY-10024.
--
Fix Version/s: 4.0.0-alpha-3
Resolution: Fixed
> Dollar slashy /$ string ending in backslash "breaks" the parser
> ---
>
> Key: GROOVY-10024
> URL: https://issues.apache.org/jira/browse/GROOVY-10024
> Project: Groovy
> Issue Type: Bug
> Components: parser
>Affects Versions: 3.0.7
>Reporter: Przemek Bielicki
>Assignee: Paul King
>Priority: Blocker
> Fix For: 4.0.0-alpha-3
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The minimal reproducer is the following:
> {code:groovy}
> def s1 = $/Failing string\\/$
> def s2 = $/Will not be parsed as a new line/$
> println s1
> {code}
> A line starting with {{def s2}} will be "swallowed". The result of it is:
> {code:java}
> Failing string\/$
> def s2 = /Will not be parsed as a new line
> {code}
> It looks like {{\/$}} is ignored by the parser and it's continuing until the
> next "valid" occurence of {{/$}}.
> It worked in 2.x
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-10026) Update the GDK to better support java streams and Publish/Subscribe API
[
https://issues.apache.org/jira/browse/GROOVY-10026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318564#comment-17318564
]
Eric Milles commented on GROOVY-10026:
--
It is also possible to implement "Stream employeeStream = employees" or
"employees as Stream" in place of "employees.stream()" but I don't find any
savings in either of those options.
> Update the GDK to better support java streams and Publish/Subscribe API
> ---
>
> Key: GROOVY-10026
> URL: https://issues.apache.org/jira/browse/GROOVY-10026
> Project: Groovy
> Issue Type: Improvement
>Affects Versions: 4.0.0-alpha-2
>Reporter: Dario Arena
>Priority: Minor
> Labels: collections, evaluation, gdk, lazy, publish, stream,
> subscribe
>
> Groovy is one of the first JVM languages to introduce "internal iteration"
> and in general collections operations like collect(), find(), collate().
> Maybe now that java has streams and a publish/subscribe API some of this
> operations could be reworked and implemented using some of this features.
> The first thing to improve could be a lazy evaluation of chained collections
> method calls, but without introducing in groovy the need to insert a
> "terminal operation" at the end of the chain.
> Just as an example if i write something like
> {quote}def employeeSorted = employee.findAll \{ it.qualification == 'intern'
> }.sort\{ daysBetween(it.hired, now) }
> if (monitorTop5Interns) \{
> print employeeSorted.take(5)
> }{quote}
> When monitorTop5Interns is false there is no need to scan all the employee
> list to find all the interns because, at least at this point in time,
> "employeeSorted" is not evaluated. Even if it is true, because of the
> "take(5)" as the last operation once top 5 elements are found there is no
> need to scan the rest of the list.
> Is it possible to implement some "intermediate decorator objects" that maybe
> extends they're correspective type (List, Set, Iterable, Collection...) that
> are automatically coerced to an actual concrete type (a java.util.ArrayList,
> a java.util.String...) only when they are actually evaluated (e.g. a
> "subscription" in the publish/subscribe semantics)?.
> I know that for every collection one could call .stream() or wrap the
> collection in a "Producer" like in RxJava but wouldn't it be groovy-er if
> this is transparent for the users?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [groovy] eric-milles commented on a change in pull request #1553: Implement GROOVY-9649: left-open and full-open ranges
eric-milles commented on a change in pull request #1553:
URL: https://github.com/apache/groovy/pull/1553#discussion_r611073061
##
File path: src/main/java/org/codehaus/groovy/ast/expr/RangeExpression.java
##
@@ -27,26 +27,42 @@
* for i in 0..10 {...}
*/
public class RangeExpression extends Expression {
-
private final Expression from;
private final Expression to;
-private final boolean inclusive;
+private final boolean inclusive; // Kept to keep old code depending on
this working
Review comment:
Can this field be dropped and `isInclusive()` is implemented in terms of
"right exclusivity"?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [groovy] eric-milles commented on a change in pull request #1553: Implement GROOVY-9649: left-open and full-open ranges
eric-milles commented on a change in pull request #1553:
URL: https://github.com/apache/groovy/pull/1553#discussion_r611073690
##
File path: src/main/java/org/codehaus/groovy/ast/expr/RangeExpression.java
##
@@ -27,26 +27,42 @@
* for i in 0..10 {...}
*/
public class RangeExpression extends Expression {
Review comment:
Is there any hope that code like AST transforms that depend on "from"
and "to" and "inclusive" will be able to handle a left-open or full-open range
literal? Is it considered a breaking change to use "<" on the left?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [groovy] eric-milles commented on a change in pull request #1553: Implement GROOVY-9649: left-open and full-open ranges
eric-milles commented on a change in pull request #1553:
URL: https://github.com/apache/groovy/pull/1553#discussion_r611073338
##
File path: src/main/java/org/codehaus/groovy/ast/expr/RangeExpression.java
##
@@ -64,10 +80,20 @@ public boolean isInclusive() {
return inclusive;
}
+public boolean isExclusiveLeft() {
+return exclusiveLeft;
+}
+
+public boolean isExclusiveRight() {
+return exclusiveRight;
+}
+
@Override
Review comment:
Would "isLeftExclusive" or "isLeftOpen" be better than
"isExclusiveLeft"? And same for right?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [groovy] eric-milles commented on a change in pull request #1553: Implement GROOVY-9649: left-open and full-open ranges
eric-milles commented on a change in pull request #1553:
URL: https://github.com/apache/groovy/pull/1553#discussion_r611073139
##
File path: src/main/java/org/codehaus/groovy/ast/expr/RangeExpression.java
##
@@ -27,26 +27,42 @@
* for i in 0..10 {...}
*/
public class RangeExpression extends Expression {
-
private final Expression from;
private final Expression to;
-private final boolean inclusive;
+private final boolean inclusive; // Kept to keep old code depending on
this working
+// GROOVY-9649
+private final boolean exclusiveLeft;
+private final boolean exclusiveRight;
+// Kept until sure this can be removed
public RangeExpression(Expression from, Expression to, boolean inclusive) {
this.from = from;
this.to = to;
this.inclusive = inclusive;
+this.exclusiveLeft = false;
+this.exclusiveRight = !inclusive;
+setType(ClassHelper.RANGE_TYPE);
Review comment:
Can this constructor delegate to the new constructor?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [groovy] eric-milles commented on a change in pull request #1553: Implement GROOVY-9649: left-open and full-open ranges
eric-milles commented on a change in pull request #1553:
URL: https://github.com/apache/groovy/pull/1553#discussion_r611073061
##
File path: src/main/java/org/codehaus/groovy/ast/expr/RangeExpression.java
##
@@ -27,26 +27,42 @@
* for i in 0..10 {...}
*/
public class RangeExpression extends Expression {
-
private final Expression from;
private final Expression to;
-private final boolean inclusive;
+private final boolean inclusive; // Kept to keep old code depending on
this working
Review comment:
Can this field be dropped and `isInclusive()` is implemented in terms of
"right inclusivity"?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (GROOVY-10026) Update the GDK to better support java streams and Publish/Subscribe API
[
https://issues.apache.org/jira/browse/GROOVY-10026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318552#comment-17318552
]
Eric Milles commented on GROOVY-10026:
--
It is also be possible to introduce a unary operator that converts the operand
to a stream, like how "~string" returns an instance of
{{java.util.regex.Pattern}}. However, this approach is much harder for you to
experiment with on your end since it would most likely require parser changes.
> Update the GDK to better support java streams and Publish/Subscribe API
> ---
>
> Key: GROOVY-10026
> URL: https://issues.apache.org/jira/browse/GROOVY-10026
> Project: Groovy
> Issue Type: Improvement
>Affects Versions: 4.0.0-alpha-2
>Reporter: Dario Arena
>Priority: Minor
> Labels: collections, evaluation, gdk, lazy, publish, stream,
> subscribe
>
> Groovy is one of the first JVM languages to introduce "internal iteration"
> and in general collections operations like collect(), find(), collate().
> Maybe now that java has streams and a publish/subscribe API some of this
> operations could be reworked and implemented using some of this features.
> The first thing to improve could be a lazy evaluation of chained collections
> method calls, but without introducing in groovy the need to insert a
> "terminal operation" at the end of the chain.
> Just as an example if i write something like
> {quote}def employeeSorted = employee.findAll \{ it.qualification == 'intern'
> }.sort\{ daysBetween(it.hired, now) }
> if (monitorTop5Interns) \{
> print employeeSorted.take(5)
> }{quote}
> When monitorTop5Interns is false there is no need to scan all the employee
> list to find all the interns because, at least at this point in time,
> "employeeSorted" is not evaluated. Even if it is true, because of the
> "take(5)" as the last operation once top 5 elements are found there is no
> need to scan the rest of the list.
> Is it possible to implement some "intermediate decorator objects" that maybe
> extends they're correspective type (List, Set, Iterable, Collection...) that
> are automatically coerced to an actual concrete type (a java.util.ArrayList,
> a java.util.String...) only when they are actually evaluated (e.g. a
> "subscription" in the publish/subscribe semantics)?.
> I know that for every collection one could call .stream() or wrap the
> collection in a "Producer" like in RxJava but wouldn't it be groovy-er if
> this is transparent for the users?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-10026) Update the GDK to better support java streams and Publish/Subscribe API
[
https://issues.apache.org/jira/browse/GROOVY-10026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318551#comment-17318551
]
Eric Milles commented on GROOVY-10026:
--
All I can think of is shortening the ".stream()" call to possibly something
like "$(employees)". Without that first explicit step, we would need an
extension method for each stream operation like for example
"employees.filtered{ ... }" where "filtered" is short for ".stream().filter{
... }".
You can try this kind of thing out by creating a class with static methods (or
using @Category) paired with a "use" block:
{code:groovy}
class StreamExtensions {
static Stream filtered(Iterable self, Predicate
predicate) {
self.stream().filter(predicate)
}
}
...
use (StreamExtensions) {
def employeeStream = employees.filtered { ... }
}
{code}
This would let you experiment with potential extension method additions. When
you have settled on something, we can consider importing into the GDK so you
can use it without "use" -- or you could take the next step for yourself by
creating an extension module so you would get the same effect.
In terms of embedding the lazy evaluation into the existing extension methods
like "collect" and "findAll", I don't see a path forward there. The behavior
of those methods is leveraged in a lot of existing Groovy code.
> Update the GDK to better support java streams and Publish/Subscribe API
> ---
>
> Key: GROOVY-10026
> URL: https://issues.apache.org/jira/browse/GROOVY-10026
> Project: Groovy
> Issue Type: Improvement
>Affects Versions: 4.0.0-alpha-2
>Reporter: Dario Arena
>Priority: Minor
> Labels: collections, evaluation, gdk, lazy, publish, stream,
> subscribe
>
> Groovy is one of the first JVM languages to introduce "internal iteration"
> and in general collections operations like collect(), find(), collate().
> Maybe now that java has streams and a publish/subscribe API some of this
> operations could be reworked and implemented using some of this features.
> The first thing to improve could be a lazy evaluation of chained collections
> method calls, but without introducing in groovy the need to insert a
> "terminal operation" at the end of the chain.
> Just as an example if i write something like
> {quote}def employeeSorted = employee.findAll \{ it.qualification == 'intern'
> }.sort\{ daysBetween(it.hired, now) }
> if (monitorTop5Interns) \{
> print employeeSorted.take(5)
> }{quote}
> When monitorTop5Interns is false there is no need to scan all the employee
> list to find all the interns because, at least at this point in time,
> "employeeSorted" is not evaluated. Even if it is true, because of the
> "take(5)" as the last operation once top 5 elements are found there is no
> need to scan the rest of the list.
> Is it possible to implement some "intermediate decorator objects" that maybe
> extends they're correspective type (List, Set, Iterable, Collection...) that
> are automatically coerced to an actual concrete type (a java.util.ArrayList,
> a java.util.String...) only when they are actually evaluated (e.g. a
> "subscription" in the publish/subscribe semantics)?.
> I know that for every collection one could call .stream() or wrap the
> collection in a "Producer" like in RxJava but wouldn't it be groovy-er if
> this is transparent for the users?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-10026) Update the GDK to better support java streams and Publish/Subscribe API
[
https://issues.apache.org/jira/browse/GROOVY-10026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318541#comment-17318541
]
Dario Arena commented on GROOVY-10026:
--
[~emilles] yes you are right, maybe i badly explained myself. My concern was
more on making chained collections and iterators call more efficient. Recently
i was tinkering with some code that requires streaming lines of text from big
.csv files that does not fit in memory and i noticed that if i call
".collect()" on a stream the function that is called is
??public static java.util.List collect(@Nullable Object self,
groovy.lang.Closure transform)??
where in the closure i define some transformation for every element in the
stream (like if in java i use java .map(..).collect(Collectors.toList()) ) and
it works!
I was wondering if maybe there was a way to generalize this behaviour for all
collections and avoid to call .stream() at the beginning and because the GDK
itself handle lazy evaluation and "materialization" of the results in a more
transparent way for the user
> Update the GDK to better support java streams and Publish/Subscribe API
> ---
>
> Key: GROOVY-10026
> URL: https://issues.apache.org/jira/browse/GROOVY-10026
> Project: Groovy
> Issue Type: Improvement
>Affects Versions: 4.0.0-alpha-2
>Reporter: Dario Arena
>Priority: Minor
> Labels: collections, evaluation, gdk, lazy, publish, stream,
> subscribe
>
> Groovy is one of the first JVM languages to introduce "internal iteration"
> and in general collections operations like collect(), find(), collate().
> Maybe now that java has streams and a publish/subscribe API some of this
> operations could be reworked and implemented using some of this features.
> The first thing to improve could be a lazy evaluation of chained collections
> method calls, but without introducing in groovy the need to insert a
> "terminal operation" at the end of the chain.
> Just as an example if i write something like
> {quote}def employeeSorted = employee.findAll \{ it.qualification == 'intern'
> }.sort\{ daysBetween(it.hired, now) }
> if (monitorTop5Interns) \{
> print employeeSorted.take(5)
> }{quote}
> When monitorTop5Interns is false there is no need to scan all the employee
> list to find all the interns because, at least at this point in time,
> "employeeSorted" is not evaluated. Even if it is true, because of the
> "take(5)" as the last operation once top 5 elements are found there is no
> need to scan the rest of the list.
> Is it possible to implement some "intermediate decorator objects" that maybe
> extends they're correspective type (List, Set, Iterable, Collection...) that
> are automatically coerced to an actual concrete type (a java.util.ArrayList,
> a java.util.String...) only when they are actually evaluated (e.g. a
> "subscription" in the publish/subscribe semantics)?.
> I know that for every collection one could call .stream() or wrap the
> collection in a "Producer" like in RxJava but wouldn't it be groovy-er if
> this is transparent for the users?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-10025) "Assimilate" expressions from other languages (Scala, Python...)
[
https://issues.apache.org/jira/browse/GROOVY-10025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318539#comment-17318539
]
Dario Arena edited comment on GROOVY-10025 at 4/10/21, 4:53 PM:
[~daniel_sun] GINQ is very nice, i didn't know that this was coming in Groovy
4. There is even an entry in the changelog under "New Features" but i missed
it. :P (maybe when Groovy 4 will come out it would need more "highlighting").
[~emilles] These are all very good ways to implement the "every statement is
indeed an expression". I was thinking however of a more direct support from the
language itself without doing the extra step of implementing these constructs.
Maybe this could be an idea to consider for a future version of Groovy (5.0)
was (Author: darioarena87):
[~abdulsubahan] GINQ is very nice, i didn't know that this was coming in Groovy
4. There is even an entry in the changelog under "New Features" but i missed
it. :P (maybe when Groovy 4 will come out it would need more "highlighting").
[~emilles] These are all very good ways to implement the "every statement is
indeed an expression". I was thinking however of a more direct support from the
language itself without doing the extra step of implementing these constructs.
Maybe this could be an idea to consider for a future version of Groovy (5.0)
> "Assimilate" expressions from other languages (Scala, Python...)
>
>
> Key: GROOVY-10025
> URL: https://issues.apache.org/jira/browse/GROOVY-10025
> Project: Groovy
> Issue Type: Improvement
> Components: Compiler
>Affects Versions: 4.0.0-alpha-2
>Reporter: Dario Arena
>Priority: Minor
> Labels: expression, for, if, semantic, statement,
> switch-statement, syntax
>
> In some other languages (Scala, Python, Haskell, Java 14 switches) every
> statement like if..else, for, switch... is indeed an expression that returns
> a value (usually the last one computed is implicitly returned as in Groovy).
> Would it be possible to include something like conditional expression, for
> comprehensions and switch expressions as a native groovy feature? I think it
> would simplify writing DSLs and maybe in some cases making groovy code neater
> and readable
> Using closures it is possible to write "conditional expressions" without
> using the conditional operator, something like:
> {quote}{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue"
> }.call()}}{quote}
> but maybe if groovy supports expression this could be written as
> {quote}{{def pillToTake = if candidate.name == "Neo" then "red" else
> "blue"}}{quote}
> or maybe using switch expression to include more complex cases
> {quote}def trainingSchedule = switch(date) \{
> case \{ isHoliday(it) }: return ['Rest']
> case \{ date.dayOfWeek in [MONDAY, FRIDAY] }: return ['Run 15m', '40
> Push-Ups', '20 Crunches']
> case \{date.dayOfWeek.is(WEDNESDAY) }: return ['Run 10m', '50
> Tractions', '30 Squats']
> default: return ['Run 30m']
> }{quote}
> I've not really dug deep in how the groovy compiler works but maybe
> recognizing these expression, "wrapping" them in a closure and calling that
> closure could be done automatically?
> For comprehensions maybe are a little bit more tricky to implement as a
> native groovy feature and using .collect(..) the code is equally readable,
> but maybe in some cases one could prefer to use a different construct
> Actual groovy code:
> {quote}def prices = stocks.filter \{ it.market == "NASDAQ"}.collect\{
> getPriceFor(it) \}{quote}
> Using for comprehension:
> {quote}def prices = [getPriceFor(stock) for stock in stocks if stock.market
> == "NASDAQ"]{quote}
> It is just a matter of preference which one is more readable but this could
> simplify the "flow" of the code in some cases.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-10025) "Assimilate" expressions from other languages (Scala, Python...)
[
https://issues.apache.org/jira/browse/GROOVY-10025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318539#comment-17318539
]
Dario Arena edited comment on GROOVY-10025 at 4/10/21, 4:53 PM:
[~daniel_sun] GINQ is very nice, i didn't know that this was coming in Groovy
4. There is even an entry in the changelog under "New Features" but i missed it
:P (maybe when Groovy 4 will come out it would need more "highlighting").
[~emilles] These are all very good ways to implement the "every statement is
indeed an expression". I was thinking however of a more direct support from the
language itself without doing the extra step of implementing these constructs.
Maybe this could be an idea to consider for a future version of Groovy (5.0)
was (Author: darioarena87):
[~daniel_sun] GINQ is very nice, i didn't know that this was coming in Groovy
4. There is even an entry in the changelog under "New Features" but i missed
it. :P (maybe when Groovy 4 will come out it would need more "highlighting").
[~emilles] These are all very good ways to implement the "every statement is
indeed an expression". I was thinking however of a more direct support from the
language itself without doing the extra step of implementing these constructs.
Maybe this could be an idea to consider for a future version of Groovy (5.0)
> "Assimilate" expressions from other languages (Scala, Python...)
>
>
> Key: GROOVY-10025
> URL: https://issues.apache.org/jira/browse/GROOVY-10025
> Project: Groovy
> Issue Type: Improvement
> Components: Compiler
>Affects Versions: 4.0.0-alpha-2
>Reporter: Dario Arena
>Priority: Minor
> Labels: expression, for, if, semantic, statement,
> switch-statement, syntax
>
> In some other languages (Scala, Python, Haskell, Java 14 switches) every
> statement like if..else, for, switch... is indeed an expression that returns
> a value (usually the last one computed is implicitly returned as in Groovy).
> Would it be possible to include something like conditional expression, for
> comprehensions and switch expressions as a native groovy feature? I think it
> would simplify writing DSLs and maybe in some cases making groovy code neater
> and readable
> Using closures it is possible to write "conditional expressions" without
> using the conditional operator, something like:
> {quote}{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue"
> }.call()}}{quote}
> but maybe if groovy supports expression this could be written as
> {quote}{{def pillToTake = if candidate.name == "Neo" then "red" else
> "blue"}}{quote}
> or maybe using switch expression to include more complex cases
> {quote}def trainingSchedule = switch(date) \{
> case \{ isHoliday(it) }: return ['Rest']
> case \{ date.dayOfWeek in [MONDAY, FRIDAY] }: return ['Run 15m', '40
> Push-Ups', '20 Crunches']
> case \{date.dayOfWeek.is(WEDNESDAY) }: return ['Run 10m', '50
> Tractions', '30 Squats']
> default: return ['Run 30m']
> }{quote}
> I've not really dug deep in how the groovy compiler works but maybe
> recognizing these expression, "wrapping" them in a closure and calling that
> closure could be done automatically?
> For comprehensions maybe are a little bit more tricky to implement as a
> native groovy feature and using .collect(..) the code is equally readable,
> but maybe in some cases one could prefer to use a different construct
> Actual groovy code:
> {quote}def prices = stocks.filter \{ it.market == "NASDAQ"}.collect\{
> getPriceFor(it) \}{quote}
> Using for comprehension:
> {quote}def prices = [getPriceFor(stock) for stock in stocks if stock.market
> == "NASDAQ"]{quote}
> It is just a matter of preference which one is more readable but this could
> simplify the "flow" of the code in some cases.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-10025) "Assimilate" expressions from other languages (Scala, Python...)
[
https://issues.apache.org/jira/browse/GROOVY-10025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318539#comment-17318539
]
Dario Arena commented on GROOVY-10025:
--
[~abdulsubahan] GINQ is very nice, i didn't know that this was coming in Groovy
4. There is even an entry in the changelog under "New Features" but i missed
it. :P (maybe when Groovy 4 will come out it would need more "highlighting").
[~emilles] These are all very good ways to implement the "every statement is
indeed an expression". I was thinking however of a more direct support from the
language itself without doing the extra step of implementing these constructs.
Maybe this could be an idea to consider for a future version of Groovy (5.0)
> "Assimilate" expressions from other languages (Scala, Python...)
>
>
> Key: GROOVY-10025
> URL: https://issues.apache.org/jira/browse/GROOVY-10025
> Project: Groovy
> Issue Type: Improvement
> Components: Compiler
>Affects Versions: 4.0.0-alpha-2
>Reporter: Dario Arena
>Priority: Minor
> Labels: expression, for, if, semantic, statement,
> switch-statement, syntax
>
> In some other languages (Scala, Python, Haskell, Java 14 switches) every
> statement like if..else, for, switch... is indeed an expression that returns
> a value (usually the last one computed is implicitly returned as in Groovy).
> Would it be possible to include something like conditional expression, for
> comprehensions and switch expressions as a native groovy feature? I think it
> would simplify writing DSLs and maybe in some cases making groovy code neater
> and readable
> Using closures it is possible to write "conditional expressions" without
> using the conditional operator, something like:
> {quote}{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue"
> }.call()}}{quote}
> but maybe if groovy supports expression this could be written as
> {quote}{{def pillToTake = if candidate.name == "Neo" then "red" else
> "blue"}}{quote}
> or maybe using switch expression to include more complex cases
> {quote}def trainingSchedule = switch(date) \{
> case \{ isHoliday(it) }: return ['Rest']
> case \{ date.dayOfWeek in [MONDAY, FRIDAY] }: return ['Run 15m', '40
> Push-Ups', '20 Crunches']
> case \{date.dayOfWeek.is(WEDNESDAY) }: return ['Run 10m', '50
> Tractions', '30 Squats']
> default: return ['Run 30m']
> }{quote}
> I've not really dug deep in how the groovy compiler works but maybe
> recognizing these expression, "wrapping" them in a closure and calling that
> closure could be done automatically?
> For comprehensions maybe are a little bit more tricky to implement as a
> native groovy feature and using .collect(..) the code is equally readable,
> but maybe in some cases one could prefer to use a different construct
> Actual groovy code:
> {quote}def prices = stocks.filter \{ it.market == "NASDAQ"}.collect\{
> getPriceFor(it) \}{quote}
> Using for comprehension:
> {quote}def prices = [getPriceFor(stock) for stock in stocks if stock.market
> == "NASDAQ"]{quote}
> It is just a matter of preference which one is more readable but this could
> simplify the "flow" of the code in some cases.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GROOVY-10023) Remove BSF from Groovy 4
[ https://issues.apache.org/jira/browse/GROOVY-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Milles reassigned GROOVY-10023: Assignee: Paul King > Remove BSF from Groovy 4 > > > Key: GROOVY-10023 > URL: https://issues.apache.org/jira/browse/GROOVY-10023 > Project: Groovy > Issue Type: Task >Reporter: Paul King >Assignee: Paul King >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-10028) Add support for type conversion from Stream to array/collection/list/set
[
https://issues.apache.org/jira/browse/GROOVY-10028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-10028:
-
Issue Type: Improvement (was: Bug)
> Add support for type conversion from Stream to array/collection/list/set
>
>
> Key: GROOVY-10028
> URL: https://issues.apache.org/jira/browse/GROOVY-10028
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-jdk
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Minor
>
> Consider the following:
> {code:groovy}
> void test(source) {
> Number[] array = source
> println array.class
> println array
> Collection coll = source
> println coll.class
> println coll
> List list = source
> println list.class
> println list
> Set set = source
> println set.class
> println set
> }
> test(new int[] {1,2,3})
> test(Arrays.asList(1,2,3))
> test(Arrays.stream(1,2,3))
> {code}
> Groovy supports automatic/implicit conversion from array to
> array/collection/list/set. And similarly for list to array or set (a list is
> already a collection/iterable). Can the type conversion logic be extended to
> support {{java.util.stream.Stream}} as a source for array/collection/list/set
> to eliminate the need for ".toArray()", ".toList()", ".toSet()" and
> ".collect(...)" in common situations?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-10029) SC: produce direct method call for assignment of collection to array
[
https://issues.apache.org/jira/browse/GROOVY-10029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-10029:
-
Issue Type: Improvement (was: Bug)
> SC: produce direct method call for assignment of collection to array
>
>
> Key: GROOVY-10029
> URL: https://issues.apache.org/jira/browse/GROOVY-10029
> Project: Groovy
> Issue Type: Improvement
> Components: Static compilation
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Minor
>
> Consider the following:
> {code:groovy}
> @groovy.transform.CompileStatic
> void test() {
> def list = [1, 2, 3, 4]
> Number[] array = list
> println array
> }
> test()
> {code}
> Groovy supports the implicit conversion "array = list" under STC/SC as of
> GROOVY-10002 and GROOVY-8983. Can the static compilation mode replace the
> call to {{ScriptBytecodeAdapter#castToType}} with a direct call to the
> collection's {{toArray()}} or {{toArray(T[])}}?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-10029) SC: produce direct method call for assignment of collection to array
[
https://issues.apache.org/jira/browse/GROOVY-10029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-10029:
-
Description:
Consider the following:
{code:groovy}
@groovy.transform.CompileStatic
void test() {
def list = [1, 2, 3, 4]
Number[] array = list
println array
}
test()
{code}
Groovy supports the implicit conversion "array = list" under STC/SC as of
GROOVY-10002 and GROOVY-8983. Can the static compilation mode replace the call
to {{ScriptBytecodeAdapter#castToType}} with a direct call to the collection's
{{toArray()}} or {{toArray(T[])}}?
was:
Consider the following:
{code:groovy}
@groovy.transform.CompileStatic
void test() {
def list = [1, 2, 3, 4]
Number[] array = list
println array
}
test()
{code}
Groovy supports the implicit conversion "array = list" under STC/SC as of
GROOVY-10002 and GROOVY-8983. Can the static compilation mode replace the call
to {{ScriptBytecodeAdapter#castToType}} with a direct call to the collection's
{{toArray()}} or {{toArray(T[])}} or the extension method {{toArray(Class)}}?
> SC: produce direct method call for assignment of collection to array
>
>
> Key: GROOVY-10029
> URL: https://issues.apache.org/jira/browse/GROOVY-10029
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Minor
>
> Consider the following:
> {code:groovy}
> @groovy.transform.CompileStatic
> void test() {
> def list = [1, 2, 3, 4]
> Number[] array = list
> println array
> }
> test()
> {code}
> Groovy supports the implicit conversion "array = list" under STC/SC as of
> GROOVY-10002 and GROOVY-8983. Can the static compilation mode replace the
> call to {{ScriptBytecodeAdapter#castToType}} with a direct call to the
> collection's {{toArray()}} or {{toArray(T[])}}?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-10029) SC: produce direct method call for assignment of collection to array
[
https://issues.apache.org/jira/browse/GROOVY-10029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-10029:
-
Summary: SC: produce direct method call for assignment of collection to
array (was: SC: produce direct method call for for collection to array
assignment)
> SC: produce direct method call for assignment of collection to array
>
>
> Key: GROOVY-10029
> URL: https://issues.apache.org/jira/browse/GROOVY-10029
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Minor
>
> Consider the following:
> {code:groovy}
> @groovy.transform.CompileStatic
> void test() {
> def list = [1, 2, 3, 4]
> Number[] array = list
> println array
> }
> test()
> {code}
> Groovy supports the implicit conversion "array = list" under STC/SC as of
> GROOVY-10002 and GROOVY-8983. Can the static compilation mode replace the
> call to {{ScriptBytecodeAdapter#castToType}} with a direct call to the
> collection's {{toArray()}} or {{toArray(T[])}} or the extension method
> {{toArray(Class)}}?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GROOVY-10029) SC: produce direct method call for for collection to array assignment
Eric Milles created GROOVY-10029:
Summary: SC: produce direct method call for for collection to
array assignment
Key: GROOVY-10029
URL: https://issues.apache.org/jira/browse/GROOVY-10029
Project: Groovy
Issue Type: Bug
Components: Static compilation
Reporter: Eric Milles
Assignee: Eric Milles
Consider the following:
{code:groovy}
@groovy.transform.CompileStatic
void test() {
def list = [1, 2, 3, 4]
Number[] array = list
println array
}
test()
{code}
Groovy supports the implicit conversion "array = list" under STC/SC as of
GROOVY-10002 and GROOVY-8983. Can the static compilation mode replace the call
to {{ScriptBytecodeAdapter#castToType}} with a direct call to the collection's
{{toArray()}} or {{toArray(T[])}} or the extension method {{toArray(Class)}}?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-10028) Add support for type conversion from Stream to array/collection/list/set
[
https://issues.apache.org/jira/browse/GROOVY-10028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-10028:
-
Description:
Consider the following:
{code:groovy}
void test(source) {
Number[] array = source
println array.class
println array
Collection coll = source
println coll.class
println coll
List list = source
println list.class
println list
Set set = source
println set.class
println set
}
test(new int[] {1,2,3})
test(Arrays.asList(1,2,3))
test(Arrays.stream(1,2,3))
{code}
Groovy supports automatic/implicit conversion from array to
array/collection/list/set. And similarly for list to array or set (a list is
already a collection/iterable). Can the type conversion logic be extended to
support {{java.util.stream.Stream}} as a source for array/collection/list/set
to eliminate the need for ".toArray()", ".toList()", ".toSet()" and
".collect(...)" in common situations?
was:
Consider the following:
{code:groovy}
void test(source) {
Number[] array = source
println array.class
println array
Collection coll = source
println coll.class
println coll
List list = source
println list.class
println list
Set set = source
println set.class
println set
}
test(new int[] {1,2,3})
test(Arrays.asList(1,2,3))
test(Arrays.stream(1,2,3))
{code}
Groovy supports automatic/implicit conversion from array to
array/collection/list/set. And similarly for list to array or set (a list is
already a collection/iterable). Can the type conversion logic be extended to
support {{java.util.stream.Stream}} as a source for array/collection/list/set
to eliminate the need for ".toArray()", ".toList()", ".toSet()" and
".collect(...)"?
> Add support for type conversion from Stream to array/collection/list/set
>
>
> Key: GROOVY-10028
> URL: https://issues.apache.org/jira/browse/GROOVY-10028
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Minor
>
> Consider the following:
> {code:groovy}
> void test(source) {
> Number[] array = source
> println array.class
> println array
> Collection coll = source
> println coll.class
> println coll
> List list = source
> println list.class
> println list
> Set set = source
> println set.class
> println set
> }
> test(new int[] {1,2,3})
> test(Arrays.asList(1,2,3))
> test(Arrays.stream(1,2,3))
> {code}
> Groovy supports automatic/implicit conversion from array to
> array/collection/list/set. And similarly for list to array or set (a list is
> already a collection/iterable). Can the type conversion logic be extended to
> support {{java.util.stream.Stream}} as a source for array/collection/list/set
> to eliminate the need for ".toArray()", ".toList()", ".toSet()" and
> ".collect(...)" in common situations?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-10028) Add support for type conversion from Stream to array/collection/list/set
[
https://issues.apache.org/jira/browse/GROOVY-10028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-10028:
-
Description:
Consider the following:
{code:groovy}
void test(source) {
Number[] array = source
println array.class
println array
Collection coll = source
println coll.class
println coll
List list = source
println list.class
println list
Set set = source
println set.class
println set
}
test(new int[] {1,2,3})
test(Arrays.asList(1,2,3))
test(Arrays.stream(1,2,3))
{code}
Groovy supports automatic/implicit conversion from array to
array/collection/list/set. And similarly for list to array or set (a list is
already a collection/iterable). Can the type conversion logic be extended to
support {{java.util.stream.Stream}} as a source for array/collection/list/set
to eliminate the need for ".toArray()", ".toList()", ".toSet()" and
".collect(...)"?
was:
Consider the following:
{code:groovy}
void test(source) {
Number[] array = source
println array.class
println array
Collection coll = source
println coll.class
println coll
List list = source
println list.class
println list
Set set = source
println set.class
println set
}
test(new int[] {1,2,3})
test(Arrays.asList(1,2,3))
test(Arrays.stream(1,2,3))
{code}
Groovy supports automatic/implicit conversion from array to
array/collection/list/set. And similarly for list to array or set. Can the
type conversion logic be extended to support {{java.util.stream.Stream}} as a
source for array/collection/list/set to eliminate the need for ".toArray()",
".toList()", ".toSet()" and ".collect(...)"?
> Add support for type conversion from Stream to array/collection/list/set
>
>
> Key: GROOVY-10028
> URL: https://issues.apache.org/jira/browse/GROOVY-10028
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Minor
>
> Consider the following:
> {code:groovy}
> void test(source) {
> Number[] array = source
> println array.class
> println array
> Collection coll = source
> println coll.class
> println coll
> List list = source
> println list.class
> println list
> Set set = source
> println set.class
> println set
> }
> test(new int[] {1,2,3})
> test(Arrays.asList(1,2,3))
> test(Arrays.stream(1,2,3))
> {code}
> Groovy supports automatic/implicit conversion from array to
> array/collection/list/set. And similarly for list to array or set (a list is
> already a collection/iterable). Can the type conversion logic be extended to
> support {{java.util.stream.Stream}} as a source for array/collection/list/set
> to eliminate the need for ".toArray()", ".toList()", ".toSet()" and
> ".collect(...)"?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GROOVY-10028) Add support for type conversion from Stream to array/collection/list/set
Eric Milles created GROOVY-10028:
Summary: Add support for type conversion from Stream to
array/collection/list/set
Key: GROOVY-10028
URL: https://issues.apache.org/jira/browse/GROOVY-10028
Project: Groovy
Issue Type: Bug
Components: groovy-jdk
Reporter: Eric Milles
Assignee: Eric Milles
Consider the following:
{code:groovy}
void test(source) {
Number[] array = source
println array.class
println array
Collection coll = source
println coll.class
println coll
List list = source
println list.class
println list
Set set = source
println set.class
println set
}
test(new int[] {1,2,3})
test(Arrays.asList(1,2,3))
test(Arrays.stream(1,2,3))
{code}
Groovy supports automatic/implicit conversion from array to
array/collection/list/set. And similarly for list to array or set. Can the
type conversion logic be extended to support {{java.util.stream.Stream}} as a
source for array/collection/list/set to eliminate the need for ".toArray()",
".toList()", ".toSet()" and ".collect(...)"?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-10025) "Assimilate" expressions from other languages (Scala, Python...)
[
https://issues.apache.org/jira/browse/GROOVY-10025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318526#comment-17318526
]
Eric Milles edited comment on GROOVY-10025 at 4/10/21, 3:15 PM:
In the case of {{findAll}} followed by {{collect}}, you can use {{findResults}}:
{code:groovy}
def prices = stocks.findResults { if (it.market == 'NASDAQ') getPriceFor(it) }
{code}
The ternary operator has been around to provide an expression solution.
{code:groovy}
def pillToTake = (candidate.name == 'Neo' ? 'red' : 'blue')
{code}
You can use command syntax to build a solution similar to what you proposed as
long as you stay away from language keywords.
{code:groovy}
def ifX(@NamedParams([@NamedParam("then"), @NamedParam("orElse")]) Map
branches, boolean condition) {
//...
}
def pillToTake = ifX candidate.name == 'Neo', then: 'red', orElse: 'blue'
{code}
There are ways to write this that use chaining so you don't need colons or
commas.
The {{switch}} expression should be coming soon to maintain Java compatibility.
was (Author: emilles):
In the case of {{findAll}} followed by {{collect}}, you can use {{findResults}}:
{code:groovy}
def prices = stocks.findResults { if (it.market == 'NASDAQ') getPriceFor(it) }
{code}
The ternary operator has been around to provide an expression solution.
{code:groovy}
def pillToTake = (candidate.name == 'Neo' ? 'red' : 'blue')
{code}
You can use command syntax to build a solution similar to what you proposed as
long as you stay away from language keywords.
{code:groovy}
def ifX(@NamedParams([@NamedParam("then"), @NamedParam("orElse")]) Map
branches, boolean condition) {
//...
}
ifX candidate.name == 'Neo', then: 'red', orElse: 'blue'
{code}
There are ways to write this that use chaining so you don't need colons or
commas.
The {{switch}} expression should be coming soon to maintain Java compatibility.
> "Assimilate" expressions from other languages (Scala, Python...)
>
>
> Key: GROOVY-10025
> URL: https://issues.apache.org/jira/browse/GROOVY-10025
> Project: Groovy
> Issue Type: Improvement
> Components: Compiler
>Affects Versions: 4.0.0-alpha-2
>Reporter: Dario Arena
>Priority: Minor
> Labels: expression, for, if, semantic, statement,
> switch-statement, syntax
>
> In some other languages (Scala, Python, Haskell, Java 14 switches) every
> statement like if..else, for, switch... is indeed an expression that returns
> a value (usually the last one computed is implicitly returned as in Groovy).
> Would it be possible to include something like conditional expression, for
> comprehensions and switch expressions as a native groovy feature? I think it
> would simplify writing DSLs and maybe in some cases making groovy code neater
> and readable
> Using closures it is possible to write "conditional expressions" without
> using the conditional operator, something like:
> {quote}{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue"
> }.call()}}{quote}
> but maybe if groovy supports expression this could be written as
> {quote}{{def pillToTake = if candidate.name == "Neo" then "red" else
> "blue"}}{quote}
> or maybe using switch expression to include more complex cases
> {quote}def trainingSchedule = switch(date) \{
> case \{ isHoliday(it) }: return ['Rest']
> case \{ date.dayOfWeek in [MONDAY, FRIDAY] }: return ['Run 15m', '40
> Push-Ups', '20 Crunches']
> case \{date.dayOfWeek.is(WEDNESDAY) }: return ['Run 10m', '50
> Tractions', '30 Squats']
> default: return ['Run 30m']
> }{quote}
> I've not really dug deep in how the groovy compiler works but maybe
> recognizing these expression, "wrapping" them in a closure and calling that
> closure could be done automatically?
> For comprehensions maybe are a little bit more tricky to implement as a
> native groovy feature and using .collect(..) the code is equally readable,
> but maybe in some cases one could prefer to use a different construct
> Actual groovy code:
> {quote}def prices = stocks.filter \{ it.market == "NASDAQ"}.collect\{
> getPriceFor(it) \}{quote}
> Using for comprehension:
> {quote}def prices = [getPriceFor(stock) for stock in stocks if stock.market
> == "NASDAQ"]{quote}
> It is just a matter of preference which one is more readable but this could
> simplify the "flow" of the code in some cases.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-10025) "Assimilate" expressions from other languages (Scala, Python...)
[
https://issues.apache.org/jira/browse/GROOVY-10025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318526#comment-17318526
]
Eric Milles commented on GROOVY-10025:
--
In the case of {{findAll}} followed by {{collect}}, you can use {{findResults}}:
{code:groovy}
def prices = stocks.findResults { if (it.market == 'NASDAQ') getPriceFor(it) }
{code}
The ternary operator has been around to provide an expression solution.
{code:groovy}
def pillToTake = (candidate.name == 'Neo' ? 'red' : 'blue')
{code}
You can use command syntax to build a solution similar to what you proposed as
long as you stay away from language keywords.
{code:groovy}
def ifX(@NamedParams([@NamedParam("then"), @NamedParam("orElse")]) Map
branches, boolean condition) {
//...
}
ifX candidate.name == 'Neo', then: 'red', orElse: 'blue'
{code}
There are ways to write this that use chaining so you don't need colons or
commas.
The {{switch}} expression should be coming soon to maintain Java compatibility.
> "Assimilate" expressions from other languages (Scala, Python...)
>
>
> Key: GROOVY-10025
> URL: https://issues.apache.org/jira/browse/GROOVY-10025
> Project: Groovy
> Issue Type: Improvement
> Components: Compiler
>Affects Versions: 4.0.0-alpha-2
>Reporter: Dario Arena
>Priority: Minor
> Labels: expression, for, if, semantic, statement,
> switch-statement, syntax
>
> In some other languages (Scala, Python, Haskell, Java 14 switches) every
> statement like if..else, for, switch... is indeed an expression that returns
> a value (usually the last one computed is implicitly returned as in Groovy).
> Would it be possible to include something like conditional expression, for
> comprehensions and switch expressions as a native groovy feature? I think it
> would simplify writing DSLs and maybe in some cases making groovy code neater
> and readable
> Using closures it is possible to write "conditional expressions" without
> using the conditional operator, something like:
> {quote}{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue"
> }.call()}}{quote}
> but maybe if groovy supports expression this could be written as
> {quote}{{def pillToTake = if candidate.name == "Neo" then "red" else
> "blue"}}{quote}
> or maybe using switch expression to include more complex cases
> {quote}def trainingSchedule = switch(date) \{
> case \{ isHoliday(it) }: return ['Rest']
> case \{ date.dayOfWeek in [MONDAY, FRIDAY] }: return ['Run 15m', '40
> Push-Ups', '20 Crunches']
> case \{date.dayOfWeek.is(WEDNESDAY) }: return ['Run 10m', '50
> Tractions', '30 Squats']
> default: return ['Run 30m']
> }{quote}
> I've not really dug deep in how the groovy compiler works but maybe
> recognizing these expression, "wrapping" them in a closure and calling that
> closure could be done automatically?
> For comprehensions maybe are a little bit more tricky to implement as a
> native groovy feature and using .collect(..) the code is equally readable,
> but maybe in some cases one could prefer to use a different construct
> Actual groovy code:
> {quote}def prices = stocks.filter \{ it.market == "NASDAQ"}.collect\{
> getPriceFor(it) \}{quote}
> Using for comprehension:
> {quote}def prices = [getPriceFor(stock) for stock in stocks if stock.market
> == "NASDAQ"]{quote}
> It is just a matter of preference which one is more readable but this could
> simplify the "flow" of the code in some cases.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-10026) Update the GDK to better support java streams and Publish/Subscribe API
[
https://issues.apache.org/jira/browse/GROOVY-10026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318521#comment-17318521
]
Eric Milles commented on GROOVY-10026:
--
You can use the streams API in any Groovy source and mix closures or lambdas if
you find one more convenient. So you could have:
{code:groovy}
def employeeStream = employees.stream()
.filter{ it.qualification == 'intern' }.sorted{ daysBetween(it.hired, now) }
if (monitorTop5Interns) {
print employeeStream.limit(5).toList()
}
{code}
Is there a specific shorthand/syntax you're looking for? We can certainly add
an extension method here or there, like "toList()" is short for
".collect(Collectors.toList())". I think the bigger concern is supporting the
existing Groovy extensions and Java streams and then adding a 3rd solution.
> Update the GDK to better support java streams and Publish/Subscribe API
> ---
>
> Key: GROOVY-10026
> URL: https://issues.apache.org/jira/browse/GROOVY-10026
> Project: Groovy
> Issue Type: Improvement
>Affects Versions: 4.0.0-alpha-2
>Reporter: Dario Arena
>Priority: Minor
> Labels: collections, evaluation, gdk, lazy, publish, stream,
> subscribe
>
> Groovy is one of the first JVM languages to introduce "internal iteration"
> and in general collections operations like collect(), find(), collate().
> Maybe now that java has streams and a publish/subscribe API some of this
> operations could be reworked and implemented using some of this features.
> The first thing to improve could be a lazy evaluation of chained collections
> method calls, but without introducing in groovy the need to insert a
> "terminal operation" at the end of the chain.
> Just as an example if i write something like
> {quote}def employeeSorted = employee.findAll \{ it.qualification == 'intern'
> }.sort\{ daysBetween(it.hired, now) }
> if (monitorTop5Interns) \{
> print employeeSorted.take(5)
> }{quote}
> When monitorTop5Interns is false there is no need to scan all the employee
> list to find all the interns because, at least at this point in time,
> "employeeSorted" is not evaluated. Even if it is true, because of the
> "take(5)" as the last operation once top 5 elements are found there is no
> need to scan the rest of the list.
> Is it possible to implement some "intermediate decorator objects" that maybe
> extends they're correspective type (List, Set, Iterable, Collection...) that
> are automatically coerced to an actual concrete type (a java.util.ArrayList,
> a java.util.String...) only when they are actually evaluated (e.g. a
> "subscription" in the publish/subscribe semantics)?.
> I know that for every collection one could call .stream() or wrap the
> collection in a "Producer" like in RxJava but wouldn't it be groovy-er if
> this is transparent for the users?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [groovy] Exploder98 opened a new pull request #1553: Implement GROOVY-9649: left-open and full-open ranges
Exploder98 opened a new pull request #1553: URL: https://github.com/apache/groovy/pull/1553 [JIRA Issue](https://issues.apache.org/jira/browse/GROOVY-9649) This Pull request implements the above feature and adds test cases related to left- and full-open ranges. We have also added documentation. This change *should* be backwards-compatible, as old right-exclusive ranges work as before. We have tried to preserve all old constructors and methods so that this change would be as backwards-compatible as possible. A few things to note: - ranges like `0<..<1` where to and from differ by one, the range is full exclusive and to and from share the same sign (positive numbers and zero are considered to have the same sign) are created as `EmptyRange`s. This is because ranges like `0<..<-1` can still be used to index into lists. - while testing, we noticed that the following equality test produces different results when the operands are switched: ```groovy IntRange r1 = new IntRange(false, 1, 10) // "Inclusive-aware" range IntRange r2 = new IntRange(1, 10) // Non-inclusive-aware range r1.equals(r2) // Returns false r2.equals(r1) // Returns true ``` we have not changed this behaviour. While implementing the feature, we noticed some inconsistencies between different ranges, which we have not altered due to backwards compatibility: - `NumberRange` and `IntRange` contain information about their inclusivity, but `ObjectRange` inclusivity is taken into account when the range is created - in `IntRange`, the `getFrom` and `getTo` methods return the actual bounds of that range, whereas `NumberRange`'s corresponging methods return the bounds that the object was created with, even if the bounds are not actually included in the range This PR was a joint effort by 4 people: @Exploder98 @iiroki @OttoVayrynen @EricssonWilli -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] timyates commented on a change in pull request #1552: GROOVY-10024: Dollar slashy /$ string ending in backslash "breaks" th…
timyates commented on a change in pull request #1552: URL: https://github.com/apache/groovy/pull/1552#discussion_r611042118 ## File path: src/test/groovy/StringTest.groovy ## @@ -241,6 +241,11 @@ foo text = $/$//$ assert text == '$$/' + +//GROOVY-10024 +def s1 = $/abc\/$ +def s2 = $/def/$ +assert s1.size() == 4 && s2.size() == 3 Review comment: Awesome as always Paul -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] paulk-asert commented on a change in pull request #1552: GROOVY-10024: Dollar slashy /$ string ending in backslash "breaks" th…
paulk-asert commented on a change in pull request #1552: URL: https://github.com/apache/groovy/pull/1552#discussion_r611036046 ## File path: src/test/groovy/StringTest.groovy ## @@ -241,6 +241,11 @@ foo text = $/$//$ assert text == '$$/' + +//GROOVY-10024 +def s1 = $/abc\/$ +def s2 = $/def/$ +assert s1.size() == 4 && s2.size() == 3 Review comment: The double backslash case works - I'll adjust the test accordingly and also with expected values. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] timyates commented on a change in pull request #1552: GROOVY-10024: Dollar slashy /$ string ending in backslash "breaks" th…
timyates commented on a change in pull request #1552: URL: https://github.com/apache/groovy/pull/1552#discussion_r611026826 ## File path: src/test/groovy/StringTest.groovy ## @@ -241,6 +241,11 @@ foo text = $/$//$ assert text == '$$/' + +//GROOVY-10024 +def s1 = $/abc\/$ +def s2 = $/def/$ +assert s1.size() == 4 && s2.size() == 3 Review comment: Does ``` def s1 = $/Failing string\\/$ ``` With double backslash at the end work (as per the Jira example)? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (GROOVY-10025) "Assimilate" expressions from other languages (Scala, Python...)
[
https://issues.apache.org/jira/browse/GROOVY-10025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318467#comment-17318467
]
Daniel Sun commented on GROOVY-10025:
-
As for the list comprehension, Groovy 4 supports it via GINQ:
{code:groovy}
def prices = GQL { from stock in stocks where stock.market == "NASDAQ" select
getPriceFor(stock) }
{code}
See
https://docs.groovy-lang.org/docs/next/html/documentation/#_querying_collections_in_sql_like_style
> "Assimilate" expressions from other languages (Scala, Python...)
>
>
> Key: GROOVY-10025
> URL: https://issues.apache.org/jira/browse/GROOVY-10025
> Project: Groovy
> Issue Type: Improvement
> Components: Compiler
>Affects Versions: 4.0.0-alpha-2
>Reporter: Dario Arena
>Priority: Minor
> Labels: expression, for, if, semantic, statement,
> switch-statement, syntax
>
> In some other languages (Scala, Python, Haskell, Java 14 switches) every
> statement like if..else, for, switch... is indeed an expression that returns
> a value (usually the last one computed is implicitly returned as in Groovy).
> Would it be possible to include something like conditional expression, for
> comprehensions and switch expressions as a native groovy feature? I think it
> would simplify writing DSLs and maybe in some cases making groovy code neater
> and readable
> Using closures it is possible to write "conditional expressions" without
> using the conditional operator, something like:
> {quote}{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue"
> }.call()}}{quote}
> but maybe if groovy supports expression this could be written as
> {quote}{{def pillToTake = if candidate.name == "Neo" then "red" else
> "blue"}}{quote}
> or maybe using switch expression to include more complex cases
> {quote}def trainingSchedule = switch(date) \{
> case \{ isHoliday(it) }: return ['Rest']
> case \{ date.dayOfWeek in [MONDAY, FRIDAY] }: return ['Run 15m', '40
> Push-Ups', '20 Crunches']
> case \{date.dayOfWeek.is(WEDNESDAY) }: return ['Run 10m', '50
> Tractions', '30 Squats']
> default: return ['Run 30m']
> }{quote}
> I've not really dug deep in how the groovy compiler works but maybe
> recognizing these expression, "wrapping" them in a closure and calling that
> closure could be done automatically?
> For comprehensions maybe are a little bit more tricky to implement as a
> native groovy feature and using .collect(..) the code is equally readable,
> but maybe in some cases one could prefer to use a different construct
> Actual groovy code:
> {quote}def prices = stocks.filter \{ it.market == "NASDAQ"}.collect\{
> getPriceFor(it) \}{quote}
> Using for comprehension:
> {quote}def prices = [getPriceFor(stock) for stock in stocks if stock.market
> == "NASDAQ"]{quote}
> It is just a matter of preference which one is more readable but this could
> simplify the "flow" of the code in some cases.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [groovy] pbielicki commented on a change in pull request #1552: GROOVY-10024: Dollar slashy /$ string ending in backslash "breaks" th…
pbielicki commented on a change in pull request #1552: URL: https://github.com/apache/groovy/pull/1552#discussion_r611023878 ## File path: src/test/groovy/StringTest.groovy ## @@ -241,6 +241,11 @@ foo text = $/$//$ assert text == '$$/' + +//GROOVY-10024 +def s1 = $/abc\/$ +def s2 = $/def/$ +assert s1.size() == 4 && s2.size() == 3 Review comment: I’d assert expected values instead of size alone. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] pbielicki commented on a change in pull request #1552: GROOVY-10024: Dollar slashy /$ string ending in backslash "breaks" th…
pbielicki commented on a change in pull request #1552: URL: https://github.com/apache/groovy/pull/1552#discussion_r611023878 ## File path: src/test/groovy/StringTest.groovy ## @@ -241,6 +241,11 @@ foo text = $/$//$ assert text == '$$/' + +//GROOVY-10024 +def s1 = $/abc\/$ +def s2 = $/def/$ +assert s1.size() == 4 && s2.size() == 3 Review comment: I’d assert the expected values instead of the size. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] danielsun1106 commented on pull request #1550: GROOVY-10023: Remove BSF module from Groovy 4
danielsun1106 commented on pull request #1550: URL: https://github.com/apache/groovy/pull/1550#issuecomment-817109305 +1 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] danielsun1106 commented on pull request #1552: GROOVY-10024: Dollar slashy /$ string ending in backslash "breaks" th…
danielsun1106 commented on pull request #1552: URL: https://github.com/apache/groovy/pull/1552#issuecomment-817109100 The test result is green ;-) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] danielsun1106 commented on pull request #1552: GROOVY-10024: Dollar slashy /$ string ending in backslash "breaks" th…
danielsun1106 commented on pull request #1552: URL: https://github.com/apache/groovy/pull/1552#issuecomment-817106706 LGTM. Let's wait for the test result: https://github.com/danielsun1106/groovy-parser/tree/GROOVY-10024 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
