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

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

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

   > (3) The snippet with `int threshold = 5` inside the query does not 
compile, with or without the bridge. `VariableScopeVisitor` rejects a local 
that is already declared in an enclosing scope, including a closure parameter 
that reuses a local name. I did not special-case that into something Groovy 
otherwise forbids.
   
   I think there is a misunderstanding. That was not supposed to be two local 
variables, that was supposed to be a field/property and a local variable.
    
   > (5) The whole lowered query closure is still compiled dynamically. I tried 
not to do that.
   > 
   > `makeDynamic` on each operator is not enough for codegen. 
`StaticTypesCallSiteWriter` throws on an operator it cannot prove, and a row 
comparison is that operator. Rewriting the operators to `ScriptBytecodeAdapter` 
calls compiled the comparison and then broke `orderby x in desc` (`in` is not a 
predicate there), join conditions, and the parameter types of parallel clause 
lambdas. A static lambda also cannot capture a local of an enclosing closure, 
which is the snapshot array: the bytecode loads the outer class and casts it to 
`GroovyObject`.
   
   I think you misunderstood the point was not that the closure is dynamic, the 
point was that it forces *anything* withing to be dynamic. It may change what 
another transform intended
   
    




> 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