[#GROOVY-2892] Unless / If expressions support

groovy

Unless / If expressions support

Created: 09/Jun/08 03:05 PM Updated: Yesterday 02:22 AM

Component/s:

syntax

Affects Version/s:

None

Fix Version/s:

None

Time Tracking:

Not Specified

Description

« Hide

I would love to see Groovy support right-side unless / if expressions like in Python or Ruby as they make the code often more readable.

Here is a small example:

doSomething() unless (x > 10)

(...)

triggerSomethingNasty() if (x < 10)

All

Comments

Work Log

Change History

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

Jochen Theodorou - 09/Jun/08 03:48 PM

what we could have is

unless(x>10){doSomething}

which is more or less like an if with a negated condition. The other order is a bit problematic in Groovy because there is no execution style like that in all of groovy. That would mean adding a new idiom, which makes the language more complicated. What could be done, would maybe:

{doSomething}.unless(x>10)

which is not exactly like in Python, but I think that is good enough. For this solution a category could be used to see if it is good.

[ Permlink | « Hide ]

Julien Ponge - 10/Jun/08 02:27 PM

That could indeed be a solution.

I understand that allowing the form I mentioned would require a change in the grammar. However I think that this would not require much changes. I am not familiar with the Groovy parser and the AST that it generates, but a naive solution would be to transform an AST such as:

            r_conditional("unless")
            /            \
      b=true_branch      c=condition

to:

            if (not c)
            /
            b

[ Permlink | « Hide ]

Jochen Theodorou - 10/Jun/08 04:01 PM

representing this in the AST is not the primary issue here. There are several idioms in Groovy and most of our grammar is based on different forms of method calls. For example

if (b) {println foo}

can be seen as a method call to the method "if" with two parameters that are "b" and the block "{println foo}". When I now look at

doSomething() unless (x > 10)

then I see a method call "doSomething()" like before with the if, but what follows? I can't be a method call if multiple arguments, because of the () and because no block follows. So what is it then? The solution I showed is based on an expression consisting of

{doSomething()}

and a method called on the result of that expression. So in my view it does not fit the overall style used in Groovy and I am tempted to say no to this, if your example is the only usage of a whole new idiom.

[ Permlink | « Hide ]

Paul King - 13/Jun/08 04:47 AM

If we bring back in the do ... while loop, we could potentially support:

if (condition) { ... }
unless (condition) { ... }
do { ... } while (condition)
do { ... } if (condition)
do { ... } unless (condition)

[ Permlink | « Hide ]

Robert Fischer - 23/Jun/08 10:46 AM

I'd rather do {...}.unless(condition) – putting conditional methods onto closures would be pretty nifty, and keep with the Groovy feel.

[ Permlink | « Hide ]

Jochen Theodorou - 01/Sep/08 10:51 AM

Julien, I would suggest you raise the issue on the groovy-user list to see the reactions of others.

[ Permlink | « Hide ]

Julien Ponge - 04/Sep/08 02:39 PM

Done. Let's see what people think about the idea

[ Permlink | « Hide ]

Luke Daley - 04/Sep/08 07:23 PM

+1000 for unless, except I think we should stick with pre statement rather post statement. To be clear...

unless (x > 10) doSomething()

if (x < 10) triggerSomethingNasty()

I actually prefer the ruby/perl style of having the condition afterwards for single statement expressions, but since Groovy already supports having the condition before the statement I would advocate sticking with this.

[ Permlink | « Hide ]

Russel Winder - 05/Sep/08 01:19 AM

I think having conditions as right-hand side properties of an expression is awful – especially in a read left-to-right language. Just because Perl and Ruby do it doesn't make it good and desirable – Python doesn't have the structure as was originally stated.

[ Permlink | « Hide ]

Julien Ponge - 05/Sep/08 01:25 AM

My mistake, Python indeed doesn't have those constructs.

[ Permlink | « Hide ]

Russel Winder - 05/Sep/08 02:22 AM

No problem, I just wanted to ensure no mistakes got turned into facts

It seems the debate is lively and alive on the mailing list, so I guess the best bet is to wait for things to iterate to a conclusion there and then post a summary item here.