[jira] [Updated] (GROOVY-8261) Faulty getText implementations for ExpressionStatement & ThrowStatement
[
https://issues.apache.org/jira/browse/GROOVY-8261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-8261:
--
Fix Version/s: 2.4.13
> Faulty getText implementations for ExpressionStatement & ThrowStatement
> ---
>
> Key: GROOVY-8261
> URL: https://issues.apache.org/jira/browse/GROOVY-8261
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: Jesse Glick
>Priority: Trivial
> Fix For: 2.4.13
>
>
> Retroactively filing for [PR 574|https://github.com/apache/groovy/pull/574].
> Expression statements printed a {{toString}} representation which did not
> even vaguely resemble source code; you would expect the same source as the
> expression itself. {{throw}} statements did not get printed at all, just an
> unimplemented placeholder.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8261) Faulty getText implementations for ExpressionStatement & ThrowStatement
[
https://issues.apache.org/jira/browse/GROOVY-8261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16091151#comment-16091151
]
Paul King commented on GROOVY-8261:
---
I think merging all the way back to 2_4_X should be fine. Thanks for the PR.
> Faulty getText implementations for ExpressionStatement & ThrowStatement
> ---
>
> Key: GROOVY-8261
> URL: https://issues.apache.org/jira/browse/GROOVY-8261
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: Jesse Glick
>Priority: Trivial
> Fix For: 2.4.13
>
>
> Retroactively filing for [PR 574|https://github.com/apache/groovy/pull/574].
> Expression statements printed a {{toString}} representation which did not
> even vaguely resemble source code; you would expect the same source as the
> expression itself. {{throw}} statements did not get printed at all, just an
> unimplemented placeholder.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (GROOVY-8261) Faulty getText implementations for ExpressionStatement & ThrowStatement
[
https://issues.apache.org/jira/browse/GROOVY-8261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-8261:
--
Affects Version/s: 2.4.12
> Faulty getText implementations for ExpressionStatement & ThrowStatement
> ---
>
> Key: GROOVY-8261
> URL: https://issues.apache.org/jira/browse/GROOVY-8261
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: Jesse Glick
>Priority: Trivial
> Fix For: 2.4.13
>
>
> Retroactively filing for [PR 574|https://github.com/apache/groovy/pull/574].
> Expression statements printed a {{toString}} representation which did not
> even vaguely resemble source code; you would expect the same source as the
> expression itself. {{throw}} statements did not get printed at all, just an
> unimplemented placeholder.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8261) Faulty getText implementations for ExpressionStatement & ThrowStatement
[
https://issues.apache.org/jira/browse/GROOVY-8261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16091148#comment-16091148
]
ASF GitHub Bot commented on GROOVY-8261:
Github user asfgit closed the pull request at:
https://github.com/apache/groovy/pull/574
> Faulty getText implementations for ExpressionStatement & ThrowStatement
> ---
>
> Key: GROOVY-8261
> URL: https://issues.apache.org/jira/browse/GROOVY-8261
> Project: Groovy
> Issue Type: Bug
>Reporter: Jesse Glick
>Priority: Trivial
>
> Retroactively filing for [PR 574|https://github.com/apache/groovy/pull/574].
> Expression statements printed a {{toString}} representation which did not
> even vaguely resemble source code; you would expect the same source as the
> expression itself. {{throw}} statements did not get printed at all, just an
> unimplemented placeholder.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] groovy pull request #574: [GROOVY-8261] Adding some getText overrides
Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/574 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (GROOVY-8258) Create a LINQ-like DSL
[
https://issues.apache.org/jira/browse/GROOVY-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16091057#comment-16091057
]
Daniel Sun commented on GROOVY-8258:
OK. I'll create a branch linq-dsl(based on master) and subproject linq-dsl at
the weekend :)
> Create a LINQ-like DSL
> --
>
> Key: GROOVY-8258
> URL: https://issues.apache.org/jira/browse/GROOVY-8258
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>
> *Pojos:*
> {code:java}
> class Category {
>String name
>List articles
> }
> class Article {
> String name
> Integer voteCount
> String categoryName
> }
> {code}
> *Example1:*
> {code:java}
> linq { // return an Iterator>
> from c of categories
> join a of articles on a.categoryName == c.name // join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> limit 100 offset 50 // pagination
> select { // create a map, its keys: articleName, voteNum, categoryName
> articleName = a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *Example2:*
> {code:java}
> linq { // return an Iterator>
> from c of categories
> join a of {
> from tempA of articles
> where tempA.voteCount > 10
> select tempA
> } on a.categoryName == c.name // join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> limit 100 offset 50 // pagination
> select { // create a map, its keys: articleName, voteNum, categoryName
> articleName = a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *Example3:*
> {code:java}
> linq { // return an Iterator
> from c of categories
> from a of c.articles // another join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> select Article { // create an Article instance
> a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *TO BE CONTINUED...*
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (GROOVY-8259) add suppressed exceptions for with[Auto]Closeable methods
[
https://issues.apache.org/jira/browse/GROOVY-8259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-8259.
---
Resolution: Fixed
Fix Version/s: 2.5.0-beta-2
Proposed PR merged.
> add suppressed exceptions for with[Auto]Closeable methods
> -
>
> Key: GROOVY-8259
> URL: https://issues.apache.org/jira/browse/GROOVY-8259
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Affects Versions: 2.5.0-beta-1
>Reporter: John Wagenleitner
>Assignee: John Wagenleitner
>Priority: Minor
> Fix For: 2.5.0-beta-2
>
>
> As with the try-with-resources statement, if multiple exceptions are thrown
> the exception from the closure should be returned and the exception from
> closing should be added as a suppressed exception.
> Currently the withCloseable/withAutoCloseable method return the closure
> exception and log a warning if an exception is thrown on the call to
> {{close()}}. With this improvement the exception from {{close()}} would also
> be added as a suppressed exception to the exception thrown from the closure.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (GROOVY-8251) Implement withCloseable on AutoCloseable
[
https://issues.apache.org/jira/browse/GROOVY-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-8251.
---
Resolution: Fixed
Assignee: John Wagenleitner
Fix Version/s: 2.5.0-beta-2
Thanks for reporting the issue. The {{withAutoCloseable}} method has been
moved from the NIO subproject to core and renamed {{withCloseable}} to be
consistent with the existing method for {{java.io.Closeable}}.
> Implement withCloseable on AutoCloseable
>
>
> Key: GROOVY-8251
> URL: https://issues.apache.org/jira/browse/GROOVY-8251
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Affects Versions: 2.5.0-beta-1
>Reporter: Henri Tremblay
>Assignee: John Wagenleitner
> Fix For: 2.5.0-beta-2
>
>
> The Groovy implementation of try-with-resource is through
> {{withCloseable()}}. The problem is that {{withCloseable}} only exists for
> classes implementing the {{Closeable}} interface.
> But a try-with-resource works with the {{AutoCloseable}} interface. So
> {{withCloseable}} should probably be moved on step below to {{AutoCloseable}}
> (that {{Closeable}} extends).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8251) Implement withCloseable on AutoCloseable
[
https://issues.apache.org/jira/browse/GROOVY-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16090961#comment-16090961
]
ASF GitHub Bot commented on GROOVY-8251:
Github user asfgit closed the pull request at:
https://github.com/apache/groovy/pull/572
> Implement withCloseable on AutoCloseable
>
>
> Key: GROOVY-8251
> URL: https://issues.apache.org/jira/browse/GROOVY-8251
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Affects Versions: 2.5.0-beta-1
>Reporter: Henri Tremblay
>
> The Groovy implementation of try-with-resource is through
> {{withCloseable()}}. The problem is that {{withCloseable}} only exists for
> classes implementing the {{Closeable}} interface.
> But a try-with-resource works with the {{AutoCloseable}} interface. So
> {{withCloseable}} should probably be moved on step below to {{AutoCloseable}}
> (that {{Closeable}} extends).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] groovy pull request #575: cache GroovyRunnerRegistry values
Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/575 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (GROOVY-8258) Create a LINQ-like DSL
[
https://issues.apache.org/jira/browse/GROOVY-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16090894#comment-16090894
]
Paul King commented on GROOVY-8258:
---
Sure, I thought that was what you were implying, I was just clarifying.
> Create a LINQ-like DSL
> --
>
> Key: GROOVY-8258
> URL: https://issues.apache.org/jira/browse/GROOVY-8258
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>
> *Pojos:*
> {code:java}
> class Category {
>String name
>List articles
> }
> class Article {
> String name
> Integer voteCount
> String categoryName
> }
> {code}
> *Example1:*
> {code:java}
> linq { // return an Iterator>
> from c of categories
> join a of articles on a.categoryName == c.name // join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> limit 100 offset 50 // pagination
> select { // create a map, its keys: articleName, voteNum, categoryName
> articleName = a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *Example2:*
> {code:java}
> linq { // return an Iterator>
> from c of categories
> join a of {
> from tempA of articles
> where tempA.voteCount > 10
> select tempA
> } on a.categoryName == c.name // join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> limit 100 offset 50 // pagination
> select { // create a map, its keys: articleName, voteNum, categoryName
> articleName = a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *Example3:*
> {code:java}
> linq { // return an Iterator
> from c of categories
> from a of c.articles // another join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> select Article { // create an Article instance
> a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *TO BE CONTINUED...*
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8258) Create a LINQ-like DSL
[
https://issues.apache.org/jira/browse/GROOVY-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16090835#comment-16090835
]
Daniel Sun commented on GROOVY-8258:
> But in terms of merging into the main branches, we could merge a PR that was
> improving the underlying APIs to make them stream-aware (without any DSL)
Agreed.
Paul, maybe I did not express the proposal clearly. The DSL should consist of
not only syntactic sugar layer but also the backend, so it will be a big work ;)
We can design DSL and implement the underlying APIs at first and then implement
the DSL, in other words, the API design is driven by the DSL. e.g. In the
following sample code, we can find we need linq, from, of, join, on, where,
orderBy, limit, offset, select methods, which will appear in our underlying
APIs.
{code:java}
linq { // return an Iterator>
from c of categories
join a of articles on a.categoryName == c.name // join
where c.name == 'Groovy'
orderBy a.voteCount desc // order by
limit 100 offset 50 // pagination
select { // create a map, its keys: articleName, voteNum, categoryName
articleName = a.name
a.voteCount
categoryName = c.name
}
}
{code}
> Create a LINQ-like DSL
> --
>
> Key: GROOVY-8258
> URL: https://issues.apache.org/jira/browse/GROOVY-8258
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>
> *Pojos:*
> {code:java}
> class Category {
>String name
>List articles
> }
> class Article {
> String name
> Integer voteCount
> String categoryName
> }
> {code}
> *Example1:*
> {code:java}
> linq { // return an Iterator>
> from c of categories
> join a of articles on a.categoryName == c.name // join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> limit 100 offset 50 // pagination
> select { // create a map, its keys: articleName, voteNum, categoryName
> articleName = a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *Example2:*
> {code:java}
> linq { // return an Iterator>
> from c of categories
> join a of {
> from tempA of articles
> where tempA.voteCount > 10
> select tempA
> } on a.categoryName == c.name // join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> limit 100 offset 50 // pagination
> select { // create a map, its keys: articleName, voteNum, categoryName
> articleName = a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *Example3:*
> {code:java}
> linq { // return an Iterator
> from c of categories
> from a of c.articles // another join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> select Article { // create an Article instance
> a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *TO BE CONTINUED...*
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8258) Create a LINQ-like DSL
[
https://issues.apache.org/jira/browse/GROOVY-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16090736#comment-16090736
]
Paul King commented on GROOVY-8258:
---
Sure, there is no problem with thinking about things from different approaches!
In fact, it's useful to go both directions sometimes. :-)
But in terms of merging into the main branches, we could merge a PR that was
improving the underlying APIs to make them stream-aware (without any DSL), but
I would most likely be -1 on a PR that was just the DSL without the underlying
API changes. Doesn't mean we have can't start an incomplete feature branch of
course to get the ball rolling.
> Create a LINQ-like DSL
> --
>
> Key: GROOVY-8258
> URL: https://issues.apache.org/jira/browse/GROOVY-8258
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>
> *Pojos:*
> {code:java}
> class Category {
>String name
>List articles
> }
> class Article {
> String name
> Integer voteCount
> String categoryName
> }
> {code}
> *Example1:*
> {code:java}
> linq { // return an Iterator>
> from c of categories
> join a of articles on a.categoryName == c.name // join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> limit 100 offset 50 // pagination
> select { // create a map, its keys: articleName, voteNum, categoryName
> articleName = a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *Example2:*
> {code:java}
> linq { // return an Iterator>
> from c of categories
> join a of {
> from tempA of articles
> where tempA.voteCount > 10
> select tempA
> } on a.categoryName == c.name // join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> limit 100 offset 50 // pagination
> select { // create a map, its keys: articleName, voteNum, categoryName
> articleName = a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *Example3:*
> {code:java}
> linq { // return an Iterator
> from c of categories
> from a of c.articles // another join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> select Article { // create an Article instance
> a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *TO BE CONTINUED...*
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (GROOVY-8261) Faulty getText implementations for ExpressionStatement & ThrowStatement
Jesse Glick created GROOVY-8261:
---
Summary: Faulty getText implementations for ExpressionStatement &
ThrowStatement
Key: GROOVY-8261
URL: https://issues.apache.org/jira/browse/GROOVY-8261
Project: Groovy
Issue Type: Bug
Reporter: Jesse Glick
Priority: Trivial
Retroactively filing for [PR 574|https://github.com/apache/groovy/pull/574].
Expression statements printed a {{toString}} representation which did not even
vaguely resemble source code; you would expect the same source as the
expression itself. {{throw}} statements did not get printed at all, just an
unimplemented placeholder.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (GROOVY-7158) minus(List, Collection) considers different objects equal if they have equal hashCodes
[
https://issues.apache.org/jira/browse/GROOVY-7158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner closed GROOVY-7158.
-
Resolution: Fixed
Assignee: John Wagenleitner
This issue was fixed by the fix for GROOVY-7530 and the [code in
question|https://github.com/apache/groovy/blob/6a8232a5ba4fdf89c7c3d1eddba68b909f4a732a/src/main/org/codehaus/groovy/runtime/NumberAwareComparator.java#L53]
now compares using {{equals}}.
> minus(List, Collection) considers different objects equal if they have equal
> hashCodes
> --
>
> Key: GROOVY-7158
> URL: https://issues.apache.org/jira/browse/GROOVY-7158
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Reporter: motto
>Assignee: John Wagenleitner
>
> This is essentially a duplicate of GROOVY-4101 and the related ticket
> GROOVY-4124.
> In [org.codehaus.groovy.runtime.DefaultGroovyMethods.minus(Collection
> self, Collection
> removeMe)|https://github.com/groovy/groovy-core/blob/master/src/main/org/codehaus/groovy/runtime/DefaultGroovyMethods.java#L10048]
> {noformat}
> Comparator numberComparator = new NumberAwareComparator();
> ...
> if (numberComparator.compare(element, (T)elt) == 0) {
> iter.remove();
> elementRemoved = true;
> }
> {noformat}
> objects not implementing
> [Comparable|http://docs.oracle.com/javase/7/docs/api/java/lang/Comparable.html]
> and without a compareTo method are compared using the
> [NumberAwareComparator|https://github.com/groovy/groovy-core/blob/master/src/main/org/codehaus/groovy/runtime/NumberAwareComparator.java#L37]
> {noformat}
> // since the object does not have a valid compareTo method
> // we compare using the hashcodes. null cases are handled by
> // DefaultTypeTransformation.compareTo
> int x1 = o1.hashCode();
> int x2 = o2.hashCode();
> if (x1 == x2) return 0;
> if (x1 < x2) return -1;
> return 1;
> {noformat}
> which incorrectly removes unequal objects from the original collection.
> This is exceedingly frustrating because the results are therefore sporadic
> and supposedly resolved according to GROOVY-4101 and GROOVY-4124. After a
> fair amount of head scratching and debugging (on more than 1 occasion) I went
> looking at the sources on github and it appears the patch has never made it
> into master. Is it possible the patch was deemed unfit? Was it forgotten
> about? Is this something I should fix myself?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (GROOVY-8258) Create a LINQ-like DSL
[
https://issues.apache.org/jira/browse/GROOVY-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16089601#comment-16089601
]
Daniel Sun edited comment on GROOVY-8258 at 7/17/17 1:30 PM:
-
Time is a problem, but we can push the progress step by step. I think we can
create a new sub-project linq-dsl at first ;)
BTW, the reason why I pay more attention to DSL is that I used to design up to
bottom.
was (Author: daniel_sun):
Time is a problem, but we can push the progress step by step. I think we can
create a new sub-project linq-dsl at first ;)
> Create a LINQ-like DSL
> --
>
> Key: GROOVY-8258
> URL: https://issues.apache.org/jira/browse/GROOVY-8258
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>
> *Pojos:*
> {code:java}
> class Category {
>String name
>List articles
> }
> class Article {
> String name
> Integer voteCount
> String categoryName
> }
> {code}
> *Example1:*
> {code:java}
> linq { // return an Iterator>
> from c of categories
> join a of articles on a.categoryName == c.name // join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> limit 100 offset 50 // pagination
> select { // create a map, its keys: articleName, voteNum, categoryName
> articleName = a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *Example2:*
> {code:java}
> linq { // return an Iterator>
> from c of categories
> join a of {
> from tempA of articles
> where tempA.voteCount > 10
> select tempA
> } on a.categoryName == c.name // join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> limit 100 offset 50 // pagination
> select { // create a map, its keys: articleName, voteNum, categoryName
> articleName = a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *Example3:*
> {code:java}
> linq { // return an Iterator
> from c of categories
> from a of c.articles // another join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> select Article { // create an Article instance
> a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *TO BE CONTINUED...*
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8258) Create a LINQ-like DSL
[
https://issues.apache.org/jira/browse/GROOVY-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16089601#comment-16089601
]
Daniel Sun commented on GROOVY-8258:
Time is a problem, but we can push the progress step by step. I think we can
create a new sub-project linq-dsl at first ;)
> Create a LINQ-like DSL
> --
>
> Key: GROOVY-8258
> URL: https://issues.apache.org/jira/browse/GROOVY-8258
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>
> *Pojos:*
> {code:java}
> class Category {
>String name
>List articles
> }
> class Article {
> String name
> Integer voteCount
> String categoryName
> }
> {code}
> *Example1:*
> {code:java}
> linq { // return an Iterator>
> from c of categories
> join a of articles on a.categoryName == c.name // join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> limit 100 offset 50 // pagination
> select { // create a map, its keys: articleName, voteNum, categoryName
> articleName = a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *Example2:*
> {code:java}
> linq { // return an Iterator>
> from c of categories
> join a of {
> from tempA of articles
> where tempA.voteCount > 10
> select tempA
> } on a.categoryName == c.name // join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> limit 100 offset 50 // pagination
> select { // create a map, its keys: articleName, voteNum, categoryName
> articleName = a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *Example3:*
> {code:java}
> linq { // return an Iterator
> from c of categories
> from a of c.articles // another join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> select Article { // create an Article instance
> a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *TO BE CONTINUED...*
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (GROOVY-8258) Create a LINQ-like DSL
[
https://issues.apache.org/jira/browse/GROOVY-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16089568#comment-16089568
]
Paul King edited comment on GROOVY-8258 at 7/17/17 9:51 AM:
[~daniel_sun] Yes, that was what I was trying to clarify and to indicate that I
think we have some more work to do at the stream API level before creating a
LINQ-like DSL layer. Obviously, you'd want to have the latter in mind when
designing the former. I don't think our current APIs are exactly what we want
to layer on top of. I was originally hoping to help contribute towards
something like this for 2.5 but haven't found time personally so far.
was (Author: paulk):
[~daniel_sun] Yes, that was what I was trying to clarify and to indicate that I
think we have some more work to do at the stream API level before creating a
LINQ-like DSL layer. Obviously, you'd want to have the latter in mind when
designing the former. I don't think our current APIs are exactly what we want
to layer on top of.
> Create a LINQ-like DSL
> --
>
> Key: GROOVY-8258
> URL: https://issues.apache.org/jira/browse/GROOVY-8258
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>
> *Pojos:*
> {code:java}
> class Category {
>String name
>List articles
> }
> class Article {
> String name
> Integer voteCount
> String categoryName
> }
> {code}
> *Example1:*
> {code:java}
> linq { // return an Iterator>
> from c of categories
> join a of articles on a.categoryName == c.name // join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> limit 100 offset 50 // pagination
> select { // create a map, its keys: articleName, voteNum, categoryName
> articleName = a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *Example2:*
> {code:java}
> linq { // return an Iterator>
> from c of categories
> join a of {
> from tempA of articles
> where tempA.voteCount > 10
> select tempA
> } on a.categoryName == c.name // join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> limit 100 offset 50 // pagination
> select { // create a map, its keys: articleName, voteNum, categoryName
> articleName = a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *Example3:*
> {code:java}
> linq { // return an Iterator
> from c of categories
> from a of c.articles // another join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> select Article { // create an Article instance
> a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *TO BE CONTINUED...*
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8258) Create a LINQ-like DSL
[
https://issues.apache.org/jira/browse/GROOVY-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16089568#comment-16089568
]
Paul King commented on GROOVY-8258:
---
[~daniel_sun] Yes, that was what I was trying to clarify and to indicate that I
think we have some more work to do at the stream API level before creating a
LINQ-like DSL layer. Obviously, you'd want to have the latter in mind when
designing the former. I don't think our current APIs are exactly what we want
to layer on top of.
> Create a LINQ-like DSL
> --
>
> Key: GROOVY-8258
> URL: https://issues.apache.org/jira/browse/GROOVY-8258
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>
> *Pojos:*
> {code:java}
> class Category {
>String name
>List articles
> }
> class Article {
> String name
> Integer voteCount
> String categoryName
> }
> {code}
> *Example1:*
> {code:java}
> linq { // return an Iterator>
> from c of categories
> join a of articles on a.categoryName == c.name // join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> limit 100 offset 50 // pagination
> select { // create a map, its keys: articleName, voteNum, categoryName
> articleName = a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *Example2:*
> {code:java}
> linq { // return an Iterator>
> from c of categories
> join a of {
> from tempA of articles
> where tempA.voteCount > 10
> select tempA
> } on a.categoryName == c.name // join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> limit 100 offset 50 // pagination
> select { // create a map, its keys: articleName, voteNum, categoryName
> articleName = a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *Example3:*
> {code:java}
> linq { // return an Iterator
> from c of categories
> from a of c.articles // another join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> select Article { // create an Article instance
> a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *TO BE CONTINUED...*
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8258) Create a LINQ-like DSL
[
https://issues.apache.org/jira/browse/GROOVY-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16089499#comment-16089499
]
Daniel Sun commented on GROOVY-8258:
LINQ will translate LINQ statement into method calls, which is like stream API
of Java 8. LINQ-like DSL is just a syntactic sugar, the backend is the stream
API.
{code:java}
// C# LINQ method calls
IQueryable source = database.Products;
var results = source.Where(product => product.ReorderLevel > 20)
.Select(product => new
{
ProductName = string.Concat("@",
product.ProductName),
UnitPrice = product.UnitPrice
});
{code}
> Create a LINQ-like DSL
> --
>
> Key: GROOVY-8258
> URL: https://issues.apache.org/jira/browse/GROOVY-8258
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>
> *Pojos:*
> {code:java}
> class Category {
>String name
>List articles
> }
> class Article {
> String name
> Integer voteCount
> String categoryName
> }
> {code}
> *Example1:*
> {code:java}
> linq { // return an Iterator>
> from c of categories
> join a of articles on a.categoryName == c.name // join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> limit 100 offset 50 // pagination
> select { // create a map, its keys: articleName, voteNum, categoryName
> articleName = a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *Example2:*
> {code:java}
> linq { // return an Iterator>
> from c of categories
> join a of {
> from tempA of articles
> where tempA.voteCount > 10
> select tempA
> } on a.categoryName == c.name // join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> limit 100 offset 50 // pagination
> select { // create a map, its keys: articleName, voteNum, categoryName
> articleName = a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *Example3:*
> {code:java}
> linq { // return an Iterator
> from c of categories
> from a of c.articles // another join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> select Article { // create an Article instance
> a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *TO BE CONTINUED...*
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (GROOVY-8260) Static compilation requires casting inside instanceof check
[
https://issues.apache.org/jira/browse/GROOVY-8260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Kleeh updated GROOVY-8260:
Description:
There are many times I find myself having to cast variables directly inside an
{{instanceof Class}} check.
In addition, I have found a specific problem with a generic {{}} where a method in the class that returns {{T}}, Groovy believes a
collection is being returned. This is the line in question:
https://github.com/grails/gorm-graphql/blob/ea6887bef0ced75d9cc0d01dc7b94d4fc0520266/core/src/main/groovy/org/grails/gorm/graphql/fetcher/impl/EntityDataFetcher.groovy#L45
The goal of this issue is to have the following codebase compile without
changes.
{{git clone -b broken_compilation https://github.com/grails/gorm-graphql}}
Attempt to compile with {{./gradlew clean classes}}
was:
There are many times I find myself having to cast variables directly inside an
{{instanceof Class}} check.
In addition, I have found a specific problem with a generic {{}} where a method in the class that returns {{T}}, Groovy believes a
collection is being returned.
The goal of this issue is to have the following codebase compile without
changes.
{{git clone -b broken_compilation https://github.com/grails/gorm-graphql}}
Attempt to compile with {{./gradlew clean classes}}
> Static compilation requires casting inside instanceof check
> ---
>
> Key: GROOVY-8260
> URL: https://issues.apache.org/jira/browse/GROOVY-8260
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.4.12
> Environment: macOS JDK 1.8
>Reporter: James Kleeh
>
> There are many times I find myself having to cast variables directly inside
> an {{instanceof Class}} check.
> In addition, I have found a specific problem with a generic {{ SomeClass>}} where a method in the class that returns {{T}}, Groovy believes
> a collection is being returned. This is the line in question:
> https://github.com/grails/gorm-graphql/blob/ea6887bef0ced75d9cc0d01dc7b94d4fc0520266/core/src/main/groovy/org/grails/gorm/graphql/fetcher/impl/EntityDataFetcher.groovy#L45
> The goal of this issue is to have the following codebase compile without
> changes.
> {{git clone -b broken_compilation https://github.com/grails/gorm-graphql}}
> Attempt to compile with {{./gradlew clean classes}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (GROOVY-8260) Static compilation requires casting inside instanceof check
James Kleeh created GROOVY-8260: --- Summary: Static compilation requires casting inside instanceof check Key: GROOVY-8260 URL: https://issues.apache.org/jira/browse/GROOVY-8260 Project: Groovy Issue Type: Bug Components: Compiler Affects Versions: 2.4.12 Environment: macOS JDK 1.8 Reporter: James Kleeh There are many times I find myself having to cast variables directly inside an `instanceof Class` check. In addition, I have found a specific problem with a generic `` where a method in the class that returns `T`, Groovy believes a collection is being returned. The goal of this issue is to have the following codebase compile without changes. `git clone -b broken_compilation https://github.com/grails/gorm-graphql` Attempt to compile with `./gradlew clean classes` -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GROOVY-8260) Static compilation requires casting inside instanceof check
[
https://issues.apache.org/jira/browse/GROOVY-8260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Kleeh updated GROOVY-8260:
Description:
There are many times I find myself having to cast variables directly inside an
{{instanceof Class}} check.
In addition, I have found a specific problem with a generic {{}} where a method in the class that returns {{T}}, Groovy believes a
collection is being returned.
The goal of this issue is to have the following codebase compile without
changes.
{{git clone -b broken_compilation https://github.com/grails/gorm-graphql}}
Attempt to compile with {{./gradlew clean classes}}
was:
There are many times I find myself having to cast variables directly inside an
`instanceof Class` check.
In addition, I have found a specific problem with a generic `` where a method in the class that returns `T`, Groovy believes a
collection is being returned.
The goal of this issue is to have the following codebase compile without
changes.
`git clone -b broken_compilation https://github.com/grails/gorm-graphql`
Attempt to compile with `./gradlew clean classes`
> Static compilation requires casting inside instanceof check
> ---
>
> Key: GROOVY-8260
> URL: https://issues.apache.org/jira/browse/GROOVY-8260
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.4.12
> Environment: macOS JDK 1.8
>Reporter: James Kleeh
>
> There are many times I find myself having to cast variables directly inside
> an {{instanceof Class}} check.
> In addition, I have found a specific problem with a generic {{ SomeClass>}} where a method in the class that returns {{T}}, Groovy believes
> a collection is being returned.
> The goal of this issue is to have the following codebase compile without
> changes.
> {{git clone -b broken_compilation https://github.com/grails/gorm-graphql}}
> Attempt to compile with {{./gradlew clean classes}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
