[GitHub] [groovy] paulk-asert opened a new pull request #1552: GROOVY-10024: Dollar slashy /$ string ending in backslash "breaks" th…
paulk-asert opened a new pull request #1552: URL: https://github.com/apache/groovy/pull/1552 …e parser -- 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] [Assigned] (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 reassigned GROOVY-10024:
--
Assignee: Paul King
> 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
>
> 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] eric-milles opened a new pull request #1551: GROOVY-10027: NamedParam: check against declared/inferred argument type
eric-milles opened a new pull request #1551: URL: https://github.com/apache/groovy/pull/1551 https://issues.apache.org/jira/browse/GROOVY-10027 -- 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] [Assigned] (GROOVY-10027) STC: NamedParams error for method call argument
[
https://issues.apache.org/jira/browse/GROOVY-10027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles reassigned GROOVY-10027:
Assignee: Eric Milles
> STC: NamedParams error for method call argument
> ---
>
> Key: GROOVY-10027
> URL: https://issues.apache.org/jira/browse/GROOVY-10027
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.5.14, 3.0.7, 4.0.0-alpha-2
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
>
> Consider the following:
> {code:groovy}
> import groovy.transform.NamedParam
> import groovy.transform.NamedParams
> @groovy.transform.TypeChecked
> //@Configuration
> class Config {
> //@Value
> String indexName
> //@Bean
> ResultType resultType() { }
> //@Bean
> def facetApplier() { new FacetApplier(index:indexName,
> resultType:resultType()) }
> }
> //@Component
> class FacetApplier {
> protected final String index
> protected final ResultType resultType
> FacetApplier(@NamedParams([
> @NamedParam(value='index', type=String, required=true),
> @NamedParam(value='resultType', type=ResultType, required=true)]) Map
> props)
> {
> this.index = props.index
> this.resultType = props.resultType
> }
> }
> class ResultType {
> }
> {code}
> Constructor call expression "new FacetApplier(index:indexName,
> resultType:resultType())" has static type checking error for "resultType"
> named parameter. {{[Static type checking] - parameter for named arg
> 'resultType' has type 'java.lang.Object' but expected 'ResultType'.}}
> If {{resultType()}} is cast or replaced with a variable, the error goes away.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-10027) STC: NamedParams error for method call argument
[
https://issues.apache.org/jira/browse/GROOVY-10027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-10027:
-
Affects Version/s: 4.0.0-alpha-2
> STC: NamedParams error for method call argument
> ---
>
> Key: GROOVY-10027
> URL: https://issues.apache.org/jira/browse/GROOVY-10027
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.5.14, 3.0.7, 4.0.0-alpha-2
>Reporter: Eric Milles
>Priority: Major
>
> Consider the following:
> {code:groovy}
> import groovy.transform.NamedParam
> import groovy.transform.NamedParams
> @groovy.transform.TypeChecked
> //@Configuration
> class Config {
> //@Value
> String indexName
> //@Bean
> ResultType resultType() { }
> //@Bean
> def facetApplier() { new FacetApplier(index:indexName,
> resultType:resultType()) }
> }
> //@Component
> class FacetApplier {
> protected final String index
> protected final ResultType resultType
> FacetApplier(@NamedParams([
> @NamedParam(value='index', type=String, required=true),
> @NamedParam(value='resultType', type=ResultType, required=true)]) Map
> props)
> {
> this.index = props.index
> this.resultType = props.resultType
> }
> }
> class ResultType {
> }
> {code}
> Constructor call expression "new FacetApplier(index:indexName,
> resultType:resultType())" has static type checking error for "resultType"
> named parameter. {{[Static type checking] - parameter for named arg
> 'resultType' has type 'java.lang.Object' but expected 'ResultType'.}}
> If {{resultType()}} is cast or replaced with a variable, the error goes away.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-10027) STC: NamedParams error for method call argument
[
https://issues.apache.org/jira/browse/GROOVY-10027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-10027:
-
Affects Version/s: 3.0.7
> STC: NamedParams error for method call argument
> ---
>
> Key: GROOVY-10027
> URL: https://issues.apache.org/jira/browse/GROOVY-10027
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.5.14, 3.0.7
>Reporter: Eric Milles
>Priority: Major
>
> Consider the following:
> {code:groovy}
> import groovy.transform.NamedParam
> import groovy.transform.NamedParams
> @groovy.transform.TypeChecked
> //@Configuration
> class Config {
> //@Value
> String indexName
> //@Bean
> ResultType resultType() { }
> //@Bean
> def facetApplier() { new FacetApplier(index:indexName,
> resultType:resultType()) }
> }
> //@Component
> class FacetApplier {
> protected final String index
> protected final ResultType resultType
> FacetApplier(@NamedParams([
> @NamedParam(value='index', type=String, required=true),
> @NamedParam(value='resultType', type=ResultType, required=true)]) Map
> props)
> {
> this.index = props.index
> this.resultType = props.resultType
> }
> }
> class ResultType {
> }
> {code}
> Constructor call expression "new FacetApplier(index:indexName,
> resultType:resultType())" has static type checking error for "resultType"
> named parameter. {{[Static type checking] - parameter for named arg
> 'resultType' has type 'java.lang.Object' but expected 'ResultType'.}}
> If {{resultType()}} is cast or replaced with a variable, the error goes away.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-10027) STC: NamedParams error for method call argument
[
https://issues.apache.org/jira/browse/GROOVY-10027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-10027:
-
Affects Version/s: 2.5.14
> STC: NamedParams error for method call argument
> ---
>
> Key: GROOVY-10027
> URL: https://issues.apache.org/jira/browse/GROOVY-10027
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.5.14
>Reporter: Eric Milles
>Priority: Major
>
> Consider the following:
> {code:groovy}
> import groovy.transform.NamedParam
> import groovy.transform.NamedParams
> @groovy.transform.TypeChecked
> //@Configuration
> class Config {
> //@Value
> String indexName
> //@Bean
> ResultType resultType() { }
> //@Bean
> def facetApplier() { new FacetApplier(index:indexName,
> resultType:resultType()) }
> }
> //@Component
> class FacetApplier {
> protected final String index
> protected final ResultType resultType
> FacetApplier(@NamedParams([
> @NamedParam(value='index', type=String, required=true),
> @NamedParam(value='resultType', type=ResultType, required=true)]) Map
> props)
> {
> this.index = props.index
> this.resultType = props.resultType
> }
> }
> class ResultType {
> }
> {code}
> Constructor call expression "new FacetApplier(index:indexName,
> resultType:resultType())" has static type checking error for "resultType"
> named parameter. {{[Static type checking] - parameter for named arg
> 'resultType' has type 'java.lang.Object' but expected 'ResultType'.}}
> If {{resultType()}} is cast or replaced with a variable, the error goes away.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GROOVY-10027) STC: NamedParams error for method call argument
Eric Milles created GROOVY-10027:
Summary: STC: NamedParams error for method call argument
Key: GROOVY-10027
URL: https://issues.apache.org/jira/browse/GROOVY-10027
Project: Groovy
Issue Type: Bug
Components: Static Type Checker
Reporter: Eric Milles
Consider the following:
{code:groovy}
import groovy.transform.NamedParam
import groovy.transform.NamedParams
@groovy.transform.TypeChecked
//@Configuration
class Config {
//@Value
String indexName
//@Bean
ResultType resultType() { }
//@Bean
def facetApplier() { new FacetApplier(index:indexName,
resultType:resultType()) }
}
//@Component
class FacetApplier {
protected final String index
protected final ResultType resultType
FacetApplier(@NamedParams([
@NamedParam(value='index', type=String, required=true),
@NamedParam(value='resultType', type=ResultType, required=true)]) Map
props)
{
this.index = props.index
this.resultType = props.resultType
}
}
class ResultType {
}
{code}
Constructor call expression "new FacetApplier(index:indexName,
resultType:resultType())" has static type checking error for "resultType" named
parameter. {{[Static type checking] - parameter for named arg 'resultType' has
type 'java.lang.Object' but expected 'ResultType'.}}
If {{resultType()}} is cast or replaced with a variable, the error goes away.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (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:all-tabpanel
]
Dario Arena updated GROOVY-10026:
-
Description:
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?
was:
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?
> 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
[jira] [Created] (GROOVY-10026) Update the GDK to better support java streams and Publish/Subscribe API
Dario Arena created GROOVY-10026:
Summary: 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
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] [Updated] (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:all-tabpanel
]
Dario Arena updated GROOVY-10026:
-
Description:
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?
was:
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?
> 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
[jira] [Updated] (GROOVY-10025) "Assimilate" expressions from other languages (Scala, Python...)
[
https://issues.apache.org/jira/browse/GROOVY-10025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dario Arena updated GROOVY-10025:
-
Description:
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.
was:
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:
def prices = [getPriceFor(stock) for stock in stocks if stock.market ==
"NASDAQ"]
It is just a matter of preference which one is more readable but this could
simplify the "flow" of the code in some cases.
> "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
[jira] [Updated] (GROOVY-10025) "Assimilate" expressions from other languages (Scala, Python...)
[
https://issues.apache.org/jira/browse/GROOVY-10025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dario Arena updated GROOVY-10025:
-
Description:
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:
def prices = [getPriceFor(stock) for stock in stocks if stock.market ==
"NASDAQ"]
It is just a matter of preference which one is more readable but this could
simplify the "flow" of the code in some cases.
was:
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:
{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue" }.call()}}
but maybe if groovy supports expression this could be written as
{{def pillToTake = if candidate.name == "Neo" then "red" else "blue"}}
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:
def prices = stocks.filter \{ it.market == "NASDAQ"}.collect\{ getPriceFor(it)
\}
Using for comprehension:
def prices = [getPriceFor(stock) for stock in stocks if stock.market ==
"NASDAQ"]
It is just a matter of preference which one is more readable but this could
simplify the "flow" of the code in some cases.
> "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
[jira] [Updated] (GROOVY-10025) "Assimilate" expressions from other languages (Scala, Python...)
[
https://issues.apache.org/jira/browse/GROOVY-10025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dario Arena updated GROOVY-10025:
-
Description:
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:
{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue" }.call()}}
but maybe if groovy supports expression this could be written as
{{def pillToTake = if candidate.name == "Neo" then "red" else "blue"}}
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:
def prices = stocks.filter \{ it.market == "NASDAQ"}.collect\{ getPriceFor(it)
\}
Using for comprehension:
def prices = [getPriceFor(stock) for stock in stocks if stock.market ==
"NASDAQ"]
It is just a matter of preference which one is more readable but this could
simplify the "flow" of the code in some cases.
was:
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:
{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue" }.call()}}
but maybe if groovy supports expression this could be written as
{{def pillToTake = if candidate.name == "Neo" then "red" else "blue"}}
or maybe using switch expression to include more complex cases
{{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']
}}}
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:
def prices = stocks.filter \{ it.market == "NASDAQ"}.collect\{ getPriceFor(it)
\}
Using for comprehension:
def prices = [getPriceFor(stock) for stock in stocks if stock.market ==
"NASDAQ"]
It is just a matter of preference which one is more readable but this could
simplify the "flow" of the code in some cases.
> "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
[jira] [Updated] (GROOVY-10025) "Assimilate" expressions from other languages (Scala, Python...)
[
https://issues.apache.org/jira/browse/GROOVY-10025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dario Arena updated GROOVY-10025:
-
Description:
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:
{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue" }.call()}}
but maybe if groovy supports expression this could be written as
{{def pillToTake = if candidate.name == "Neo" then "red" else "blue"}}
or maybe using switch expression to include more complex cases
{{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']
}}}
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:
def prices = stocks.filter \{ it.market == "NASDAQ"}.collect\{ getPriceFor(it)
\}
Using for comprehension:
def prices = [getPriceFor(stock) for stock in stocks if stock.market ==
"NASDAQ"]
It is just a matter of preference which one is more readable but this could
simplify the "flow" of the code in some cases.
was:
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:
{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue" }.call()}}
but maybe if groovy supports expression this could be written as
{{def pillToTake = if candidate.name == "Neo" then "red" else "blue"}}
or maybe using switch expression to include more complex cases
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']
}
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:
def prices = stocks.filter \{ it.market == "NASDAQ"}.collect\{ getPriceFor(it)
\}
Using for comprehension:
def prices = [getPriceFor(stock) for stock in stocks if stock.market ==
"NASDAQ"]
It is just a matter of preference which one is more readable but this could
simplify the "flow" of the code in some cases.
> "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
[jira] [Updated] (GROOVY-10025) "Assimilate" expressions from other languages (Scala, Python...)
[
https://issues.apache.org/jira/browse/GROOVY-10025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dario Arena updated GROOVY-10025:
-
Description:
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:
{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue" }.call()}}
but maybe if groovy supports expression this could be written as
{{def pillToTake = if candidate.name == "Neo" then "red" else "blue"}}
or maybe using switch expression to include more complex cases
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']
}
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:
def prices = stocks.filter \{ it.market == "NASDAQ"}.collect\{ getPriceFor(it)
\}
Using for comprehension:
def prices = [getPriceFor(stock) for stock in stocks if stock.market ==
"NASDAQ"]
It is just a matter of preference which one is more readable but this could
simplify the "flow" of the code in some cases.
was:
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:
{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue" }.call()}}
but maybe if groovy supports expression this could be written as
{{def pillToTake = if candidate.name == "Neo" then "red" else "blue"}}
or maybe using switch expression to include more complex cases
{{
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']
}
}}
{{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:}}
def prices = stocks.filter \{ it.market == "NASDAQ"}.collect\{ getPriceFor(it) }
{{Using for comprehension:}}
{{def prices = [getPriceFor(stock) for stock in stocks if stock.market ==
"NASDAQ"]}}
It is just a matter of preference which one is more readable but this could
simplify the "flow" of the code in some cases.
> "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
[jira] [Updated] (GROOVY-10025) "Assimilate" expressions from other languages (Scala, Python...)
[
https://issues.apache.org/jira/browse/GROOVY-10025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dario Arena updated GROOVY-10025:
-
Description:
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:
{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue" }.call()}}
but maybe if groovy supports expression this could be written as
{{def pillToTake = if candidate.name == "Neo" then "red" else "blue"}}
or maybe using switch expression to include more complex cases
{{
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']
}
}}
{{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:}}
def prices = stocks.filter \{ it.market == "NASDAQ"}.collect\{ getPriceFor(it) }
{{Using for comprehension:}}
{{def prices = [getPriceFor(stock) for stock in stocks if stock.market ==
"NASDAQ"]}}
It is just a matter of preference which one is more readable but this could
simplify the "flow" of the code in some cases.
was:
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:
{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue" }.call()}}
but maybe if groovy supports expression this could be written as
{{def pillToTake = if candidate.name == "Neo" then "red" else "blue"}}
or maybe using switch expression to include more complex cases
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']
{{}}}
{{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:}}
def prices = stocks.filter \{ it.market == "NASDAQ"}.collect\{ getPriceFor(it) }
{{Using for comprehension:}}
{{def prices = [getPriceFor(stock) for stock in stocks] }}
It is just a matter of preference which one is more readable but this could
simplify the "flow" of the code in some cases.
> "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
[jira] [Updated] (GROOVY-10025) "Assimilate" expressions from other languages (Scala, Python...)
[
https://issues.apache.org/jira/browse/GROOVY-10025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dario Arena updated GROOVY-10025:
-
Description:
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:
{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue" }.call()}}
but maybe if groovy supports expression this could be written as
{{def pillToTake = if candidate.name == "Neo" then "red" else "blue"}}
or maybe using switch expression to include more complex cases
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']
{{}}}
{{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:}}
def prices = stocks.filter \{ it.market == "NASDAQ"}.collect\{ getPriceFor(it) }
{{Using for comprehension:}}
{{def prices = [getPriceFor(stock) for stock in stocks] }}
It is just a matter of preference which one is more readable but this could
simplify the "flow" of the code in some cases.
was:
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:
{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue" }.call()}}
but maybe if groovy supports expression this could be written as
{{def pillToTake = if candidate.name == "Neo" then "red" else "blue"}}
or maybe using switch expression to include more complex cases
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']
{{}}}
{{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:}}
{{def prices = stocks.collect
{ getPriceFor(it) }
}}
{{Using for comprehension:}}
{{def prices = [getPriceFor(stock) for stock in stocks] }}
It is just a matter of preference which one is more readable but this could
simplify the "flow" of the code in some cases.
> "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
[jira] [Updated] (GROOVY-10025) "Assimilate" expressions from other languages (Scala, Python...)
[
https://issues.apache.org/jira/browse/GROOVY-10025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dario Arena updated GROOVY-10025:
-
Description:
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:
{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue" }.call()}}
but maybe if groovy supports expression this could be written as
{{def pillToTake = if candidate.name == "Neo" then "red" else "blue"}}
or maybe using switch expression to include more complex cases
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']
{{}}}
{{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:}}
{{def prices = stocks.collect
{ getPriceFor(it) }
}}
{{Using for comprehension:}}
{{def prices = [getPriceFor(stock) for stock in stocks] }}
It is just a matter of preference which one is more readable but this could
simplify the "flow" of the code in some cases.
was:
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:
{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue" }.call()}}
but maybe if groovy supports expression this could be written as
{{def pillToTake = if candidate.name == "Neo" then "red" else "blue"}}
or maybe using switch expression to include more complex cases
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']
{{}}}
{{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:}}
{{def prices = stocks.collect
{ getPriceFor(it) }
}}
{{Using for comprehension:}}
{{def prices = [getPriceFor(stock) for stock in stocks] }}
It is just a matter of preference which one is more readable but this could
simplify the "flow" of the code in some cases.
> "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
[jira] [Updated] (GROOVY-10025) "Assimilate" expressions from other languages (Scala, Python...)
[
https://issues.apache.org/jira/browse/GROOVY-10025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dario Arena updated GROOVY-10025:
-
Description:
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:
{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue" }.call()}}
but maybe if groovy supports expression this could be written as
{{def pillToTake = if candidate.name == "Neo" then "red" else "blue"}}
or maybe using switch expression to include more complex cases
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']
{{}}}{{}}
{{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:}}
{{def prices = stocks.collect
{ getPriceFor(it) }
}}
{{Using for comprehension:}}
{{def prices = [getPriceFor(stock) for stock in stocks] }}
It is just a matter of preference which one is more readable but this could
simplify the "flow" of the code in some cases.
was:
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:
{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue" }.call()}}
but maybe if groovy supports expression this could be written as
{{def pillToTake = if candidate.name == "Neo" then "red" else "blue"}}
or maybe using switch expression to include more complex cases
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']
}
{{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:}}
{\{def prices = stocks.collect{ getPriceFor(it) }}}
{{Using for comprehension:}}
{{def prices = [getPriceFor(stock) for stock in stocks] }}
It is just a matter of preference which one is more readable but this could
simplify the "flow" of the code in some cases.
> "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
[jira] [Updated] (GROOVY-10025) "Assimilate" expressions from other languages (Scala, Python...)
[
https://issues.apache.org/jira/browse/GROOVY-10025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dario Arena updated GROOVY-10025:
-
Description:
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:
{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue" }.call()}}
but maybe if groovy supports expression this could be written as
{{def pillToTake = if candidate.name == "Neo" then "red" else "blue"}}
or maybe using switch expression to include more complex cases
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']
{{}}}
{{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:}}
{{def prices = stocks.collect
{ getPriceFor(it) }
}}
{{Using for comprehension:}}
{{def prices = [getPriceFor(stock) for stock in stocks] }}
It is just a matter of preference which one is more readable but this could
simplify the "flow" of the code in some cases.
was:
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:
{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue" }.call()}}
but maybe if groovy supports expression this could be written as
{{def pillToTake = if candidate.name == "Neo" then "red" else "blue"}}
or maybe using switch expression to include more complex cases
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']
{{}}}{{}}
{{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:}}
{{def prices = stocks.collect
{ getPriceFor(it) }
}}
{{Using for comprehension:}}
{{def prices = [getPriceFor(stock) for stock in stocks] }}
It is just a matter of preference which one is more readable but this could
simplify the "flow" of the code in some cases.
> "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
[jira] [Updated] (GROOVY-10025) "Assimilate" expressions from other languages (Scala, Python...)
[
https://issues.apache.org/jira/browse/GROOVY-10025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dario Arena updated GROOVY-10025:
-
Description:
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:
{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue" }.call()}}
but maybe if groovy supports expression this could be written as
{{def pillToTake = if candidate.name == "Neo" then "red" else "blue"}}
or maybe using switch expression to include more complex cases
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']
}
{{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:}}
{\{def prices = stocks.collect{ getPriceFor(it) }}}
{{Using for comprehension:}}
{{def prices = [getPriceFor(stock) for stock in stocks] }}
It is just a matter of preference which one is more readable but this could
simplify the "flow" of the code in some cases.
was:
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:
{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue" }.call()}}
but maybe if groovy supports expression this could be written as
{{def pillToTake = if candidate.name == "Neo" then "red" else "blue"}}
or maybe using switch expression to include more complex cases
{{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']}}
{{}}}
{{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:}}
{{def prices = stocks.collect\{ getPriceFor(it) }}}
{{Using for comprehension:}}
{{def prices = [getPriceFor(stock) for stock in stocks] }}
It is just a matter of preference which one is more readable but this could
simplify the "flow" of the code in some cases.
> "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
[jira] [Created] (GROOVY-10025) "Assimilate" expressions from other languages (Scala, Python...)
Dario Arena created GROOVY-10025:
Summary: "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
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:
{{def pillToTake = \{ if(candidate.name == "Neo") "red" else "blue" }.call()}}
but maybe if groovy supports expression this could be written as
{{def pillToTake = if candidate.name == "Neo" then "red" else "blue"}}
or maybe using switch expression to include more complex cases
{{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']}}
{{}}}
{{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:}}
{{def prices = stocks.collect\{ getPriceFor(it) }}}
{{Using for comprehension:}}
{{def prices = [getPriceFor(stock) for stock in stocks] }}
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] [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
]
Przemek Bielicki updated GROOVY-10024:
--
Description:
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
was:
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}
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
> 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
>Priority: Blocker
>
> 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-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
]
Przemyslaw Bielicki updated GROOVY-10024:
-
Description:
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}
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
was:
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". It looks like {{\/$}} is
ignored by the parser and it's continuing until the next "valid" occurence of
{{/$}}.
It worked in 2.x
> 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: Przemyslaw Bielicki
>Priority: Blocker
>
> 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}
> 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] [Created] (GROOVY-10024) Dollar slashy /$ string ending in backslash breaks the parser
Przemyslaw Bielicki created GROOVY-10024:
Summary: 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: Przemyslaw Bielicki
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". 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-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
]
Przemyslaw Bielicki updated GROOVY-10024:
-
Summary: Dollar slashy /$ string ending in backslash "breaks" the parser
(was: Dollar slashy /$ string ending in backslash breaks the parser)
> 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: Przemyslaw Bielicki
>Priority: Blocker
>
> 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". 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] [Comment Edited] (GROOVY-10022) Bump BSF to 3.1 (Groovy 3_0_X)
[
https://issues.apache.org/jira/browse/GROOVY-10022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17317756#comment-17317756
]
Paul King edited comment on GROOVY-10022 at 4/9/21, 8:00 AM:
-
After assessing what would be included in a {{groovy-bsf}} module based on
Apache BSF 3.1, it requires the JSR-223 engine anyway, so would end up only
being a few utility classes which can be download directly as the
org.apache.bsf-utils dependency anyway. So, no need to progress this.
was (Author: paulk):
After assessing what would be included in a Apache BSF 3.1-based module, it
requires the JSR-223 engine anyway, so would end up only being a few utility
classes which can be download directly as the org.apache.bsf-utils dependency
anyway. So, no need to progress this.
> Bump BSF to 3.1 (Groovy 3_0_X)
> --
>
> Key: GROOVY-10022
> URL: https://issues.apache.org/jira/browse/GROOVY-10022
> Project: Groovy
> Issue Type: Dependency upgrade
>Reporter: Paul King
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GROOVY-10022) Bump BSF to 3.1 (Groovy 3_0_X)
[ https://issues.apache.org/jira/browse/GROOVY-10022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-10022. -- Resolution: Won't Fix After assessing what would be included in a Apache BSF 3.1-based module, it requires the JSR-223 engine anyway, so would end up only being a few utility classes which can be download directly as the org.apache.bsf-utils dependency anyway. So, no need to progress this. > Bump BSF to 3.1 (Groovy 3_0_X) > -- > > Key: GROOVY-10022 > URL: https://issues.apache.org/jira/browse/GROOVY-10022 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [groovy] paulk-asert opened a new pull request #1550: GROOVY-10023: Remove BSF module from Groovy 4
paulk-asert opened a new 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
[jira] [Created] (GROOVY-10023) Remove BSF from Groovy 4
Paul King created GROOVY-10023: -- Summary: 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 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GROOVY-10022) Bump BSF to 3.1 (Groovy 3_0_X)
Paul King created GROOVY-10022: -- Summary: Bump BSF to 3.1 (Groovy 3_0_X) Key: GROOVY-10022 URL: https://issues.apache.org/jira/browse/GROOVY-10022 Project: Groovy Issue Type: Dependency upgrade Reporter: Paul King -- This message was sent by Atlassian Jira (v8.3.4#803005)
