groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: [RFE] Methods as expressions
Date Wed, 21 Mar 2018 08:53:01 GMT


Am 21.03.2018 um 09:27 schrieb C├ędric Champeau:
[...]
> In any case, I was doubtful as you are here before actually using it in 
> Kotlin. After a few weeks, it became clear to me this syntax was both 
> more concise and more self-explanatory.

For me {} was always very clear, for {} starts a new scope, it is a 
block, that can return something. I did never even once think about 
these as expressions. That is why I really not often speak about closure 
expressions, but about attached and open blocks or Closure. And in that 
matter:

double x
double y
double surface(double x, double y) = x * y

I find it very unclear if the x is the field/property x or the method 
parameter. That is because normally = does not create a new scope. And 
especially normally = does not allow referencing variables from the left 
side declaration. For example:

class X {
def foo = 1
def bar() {
   def foo = foo*2
}}

This is allowed in Groovy and Java, because the semantics are very 
clear. Since = does not do a forward declaration the local variable foo 
is not defined on the RHS. Thus the foo on the RHS can only mean the 
property/field.

class X {
def foo = 1
def bar(foo) {
   def foo = foo*2
}}

This is not allows, because the block already declares a foo and another 
local variable of the name foo is not allowed

class X {
def foo = 1
def bar(foo) {
   def bar = foo*2
}}

This is allowed and again the semantics are clear, because the parameter 
is a local scope that shadows the class scope, thus in the declaration 
of bar the foo in RHS means the foo from the method parameter.

double surface(double x, double y) = x * y

breaks with the former declaration and scoping logic. You can try rescue 
this by saying the = in the method declaration has nothing to do with 
the = in a declaration or assignment otherwise. But if I always have to 
do the expansion to the other version to understand what happens, then 
it is not easier for me.

On top of that I am a real bad fit for this style, because except for 
demo purposes I rarely write methods that contains only a single line of 
code. Maybe you could show real world examples that show the real 
coolness of this?

bye Jochen



Mime
View raw message