groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: JSR 223 support behavior
Date Wed, 24 May 2017 07:45:33 GMT


On 24.05.2017 05:11, Assia Alexandrova wrote:
[...]
> Ok, so if I understand correctly from this and from some cursory
> reading of the source code around JSR 223, the 'def' keyword operates
> within a lexical scope and that lexical scope must be completely known
> in advance before the statement can be evaluated. There is no "global"
> lexical scope (just like there isn't in Java) that one can operate
> within in a REPL. However, there is a global dynamic scope that is
> accessible by being careful to omit the 'def' keyword (and I suppose
> type names as well?).

sounds about right... no type name either, yes.

> I must admit I don't understand what the
> semantics are, but as long as it makes some sense to Groovy users,
> that's fine.

I hope it does ;)

[...]
>>>
>>> groovy:000> def x = 10;
>>>
>>> ===> 10
>>>
>>> groovy:000> x
>>>
>>> Unknown property: x
>>
>> hmmm... strange... I have the vague memory that somebody already fixed
>> that... ah... right... this is JSR-223 not groovysh. For groovysh we
>> actually do quite some things like transferring import statements and I
>> think also declaration of variables and methods. But JSR-223 was originally
>> intended to always get a complete script, thus we have no such things there.
>> If JSR223 would be in more wider use, we would probably offer a REPL mode
>> for it...
>
> This *is* groovysh, not JSR 223. I just wanted to see how Groovy's own
> REPL behaves and it seems like it behaves the same, specifically it
> seems like every string evaluated has its own lexical scope and that
> lexical scope is lost on the next command. So one shouldn't use 'def'
> inside groovysh either if one want to declare global variables.


ah, thanks for the clarification... I thought we had changed that 
already in the past. Seems my memory was not correct here. Extracting 
the variables of the topmost scope is not the most difficult thing to do 
I will bring this to the dev list

bye Jochen

Mime
View raw message