[ 
https://issues.apache.org/jira/browse/GROOVY-12724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18142949#comment-18142949
 ] 

ASF GitHub Bot commented on GROOVY-12724:
-----------------------------------------

daniellansun commented on PR #3259:
URL: https://github.com/apache/groovy/pull/3259#issuecomment-6795258351

   (5) Follow-up to 
https://github.com/apache/groovy/pull/3259#issuecomment-6781911494.
   
   The lowered query closure is no longer marked `DYNAMIC_RESOLUTION`. Under 
`@CompileStatic` it stays on the static writer. A call the checker selects, 
including a target another extension already chose, is the method that is 
emitted.
   
   The `choose(CharSequence)` case is the one you pointed at. An extension's 
`onMethodSelection` forces `choose(CharSequence)` when the argument is a 
`String`. That target is now honoured inside `select` as well. The regression 
is `['seq', 'seq']`.
   
   A well-typed `Stream` call in a clause is also the static method the checker 
selects, including a legal method-reference SAM. A number comparison the 
checker can prove stays the operator, so `n > 1` when `n` is `Integer` is a 
primitive compare, which is what javac emits for the same program.
   
   Only precise holes stay dynamic: an unresolved call, an operator the checker 
cannot prove, and a comparison it cannot type. A list of maps is a normal GINQ 
source, so `@CompileStatic` `from r in [[a:1]] where r.missing > 1` still 
reaches `ScriptBytecodeAdapter`. `r.missing` is an untyped map read (`Object`), 
and `Object > int` is not a Java comparison; javac rejects that program. A 
number compared with a number is not on that path.
   
   `@TypeChecked` still does not statically compile the clause bodies. The 
checker does not infer the clause-lambda parameter types, so those calls stay 
dynamic. That is unchanged.
   
   A few existing tests used typings javac would reject, for example 
`reduce(BigDecimal.ZERO, BigDecimal::add)` on a stream of ints. Those were 
corrected in the smallest way that keeps the expected results, by mapping 
through `BigDecimal.valueOf` first. `Collectors.joining()` on `Stream<String>` 
was already well-typed and was left alone.
   
   `Queryable.from(int[])` now boxes to `Queryable<Integer>`. The type system 
no longer constructs `Queryable<int>` or `Serializable<T>`. `SourceRecord` has 
to stay public because `navigate` returns it and tests in another package name 
it; it is annotated `@Internal` and is not a published API.
   
   `ErrorCollector.hasErrors()` now treats an empty list as no errors. A 
listener can remove a handled diagnostic; if that was the last one, the compile 
no longer fails with a blank `startup failed`.
   
   `STRATEGY.md` and the CompileStatic section of the user guide are updated to 
match this.
   




> GINQ: support static compilation and a fluent query API
> -------------------------------------------------------
>
>                 Key: GROOVY-12724
>                 URL: https://issues.apache.org/jira/browse/GROOVY-12724
>             Project: Groovy
>          Issue Type: Improvement
>          Components: GINQ
>            Reporter: Daniel Sun
>            Assignee: Daniel Sun
>            Priority: Major
>
> Under @CompileStatic / @TypeChecked, GQ, GQL, and @GQ currently rely on 
> dynamic lowering. This improvement makes those entry points usable from a 
> statically checked scope while keeping the SQL-like syntax lowered to the 
> in-memory collection runtime.
> h3. Goals
> * Allow GQ / GQL / @GQ from @CompileStatic and @TypeChecked without forcing 
> the lowered tree through static checking at the expression site.
> * Defer pipeline construction with LazyQueryable until a terminal read 
> (toList, count, etc.), copying locals at the expression site (same binding as 
> dynamic GQ).
> * Add Ginq.from(...) as a deferred, generic fluent chain on the same runtime, 
> with @ClosureParams so where/select/join/aggregate closures can infer element 
> types where inference is sound.
> * Preserve default lazy/deferred evaluation and dynamic GQ behavior for map 
> rows and other intentionally dynamic cases.
> h3. Non-goals / known limits
> * Stored untyped Closure variables still need a SAM target type for parameter 
> inference (same as Java/C#).
> * Raw Query parameters/fields cannot recover a safe element type.
> * Names bound by from inside GQ / GQL / @GQ stay dynamic by design; callers 
> that need checked element types use Ginq.from.
> h3. Related work
> GitHub PR: https://github.com/apache/groovy/pull/3259
> Stacked on GEP-26 SQL window work (PR #3167 / gep26-sql-window).



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

Reply via email to