groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chaitanya Birudavolu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GROOVY-8952) Eager interpolation evaluating as a Closure does a lazy invoke of the Closure
Date Tue, 08 Jan 2019 12:50:00 GMT

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

Chaitanya Birudavolu commented on GROOVY-8952:
----------------------------------------------

I do not have a use case. Hence this behavior doesn't stop me from doing anything.

If there were indeed a use case, in which, we *don't want* the closure to get executed (perhaps
it is compute-intensive), and we just want closure.toString(), I suppose that could be easily
achieved by having closure.toString() as the last statement of the eager placeholder.

My only concerns are that:
 # This behavior is both counter-intuitive and not documented (counter-intuitive since it
is not consistent with the other scenarios where the enclosed expression evaluates to a *non-Closure*
type).
 # There is no clearly stated stand on whether this behavior will remain, or will likely be
changed (for consistency or other reasons). An explicit stand on this can help programmers
to make the decision to either depend or not to depend, on current behavior

> Eager interpolation evaluating as a Closure does a lazy invoke of the Closure
> -----------------------------------------------------------------------------
>
>                 Key: GROOVY-8952
>                 URL: https://issues.apache.org/jira/browse/GROOVY-8952
>             Project: Groovy
>          Issue Type: Bug
>    Affects Versions: 2.5.5
>         Environment: Windows 10
>            Reporter: Chaitanya Birudavolu
>            Priority: Major
>              Labels: closure, eager, interpolation
>
> This is regarding the eager interpolation placeholder
> {code:java}
> ${ <expression> }{code}
> The expected behavior is that the expression would be evaluated eagerly (at GString
creation time). Later, at GString coercion time, the value that is expected in the place
of the eager placeholder is the result of
> {code:java}
> <expression>.toString(){code}
>  
>  
> This works most of the time, but doesn't seem to work if the expression evaluates to
a Closure type. If the expression evaluates to a Closure type, what is observed is that, in
the place of the placeholder, instead of seeing ...
> {code:java}
> <closure>.toString(){code}
> ... we see...
> {code:java}
> <closure-invocation-result>.toString(){code}
> For example, in the below code...
>  
> {code:java}
> def c = {->println ('Inside closure')}
> println ('Just before creating the GString')
> def gstr = "${println ('Inside eager placeholder'); 20; 30; c}"
> println ('Just after creating the GString')
> println (gstr)
> {code}
>  
> ...the expected behavior is that the closure should never get executed, and the last
println should only print the result of
> {code:java}
> c.toString(){code}
> Instead, the last line printed is observed to be:
> {code:java}
> Inside closure{code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message