Jochen Theodorou | 26 Jun 20:15
Gravatar

Re: [groovy-dev] optional returns

Martin C. Martin schrieb:
> In Ruby, there's not distinction between statements and expressions. 
> There's a convention that sometimes if, for, etc. are called statements, 
> but the compiler/interpreter make no such distinction.
> 
> So looping constructs are expressions, but they always return nil, since 
> there's really no good return value for them.  It's the same reason that 
> Groovy's "each" doesn't return anything.

I think we changed each to return the object we iterate on, so in 
list.each{println it} we will return the list...

> switch statements (which Ruby calls "case" statements) return a value. 
> Here's the first example of their use in Matz's book on Ruby:
> 
> # Determine US generation name based on birth year
> # Case expression tests ranges with ===
> generation = case birthyear
>              when 1946..1963: "Baby Boomer"
>              when 1964..1976: "Generation X"
>              when 1978..2000: "Generation Y"
>              else nil
>              end

yes, I think we really should keep in mind, that Groovy has statements 
and expressions, while others have probably only expressions. That is a 
huge difference. And starting to let statements return something, means 
in the end to let all statements become expressions.

bye blackdrag
(Continue reading)

Marc Palmer | 26 Jun 21:38
Favicon
Gravatar

Re: [groovy-dev] optional returns


On 26 Jun 2008, at 19:15, Jochen Theodorou wrote:

> Martin C. Martin schrieb:
>> In Ruby, there's not distinction between statements and  
>> expressions. There's a convention that sometimes if, for, etc. are  
>> called statements, but the compiler/interpreter make no such  
>> distinction.
>> So looping constructs are expressions, but they always return nil,  
>> since there's really no good return value for them.  It's the same  
>> reason that Groovy's "each" doesn't return anything.
>
> I think we changed each to return the object we iterate on, so in  
> list.each{println it} we will return the list...
>
>> switch statements (which Ruby calls "case" statements) return a  
>> value. Here's the first example of their use in Matz's book on Ruby:
>> # Determine US generation name based on birth year
>> # Case expression tests ranges with ===
>> generation = case birthyear
>>             when 1946..1963: "Baby Boomer"
>>             when 1964..1976: "Generation X"
>>             when 1978..2000: "Generation Y"
>>             else nil
>>             end
>
> yes, I think we really should keep in mind, that Groovy has  
> statements and expressions, while others have probably only  
> expressions. That is a huge difference. And starting to let  
> statements return something, means in the end to let all statements  
(Continue reading)

Jochen Theodorou | 26 Jun 21:49
Gravatar

Re: [groovy-dev] optional returns

Marc Palmer schrieb:
[...]
> def a() { "hello" }
> void b() { ... }
> 
> def work() {
>     a()
>     b()
> }
> 
> What is the return value of work? null or "hello", or a compiler error? 
> I can't recall at the moment.

we handle void as something that returns null.

> Also take this scenario:
> 
> def something() {
>   a()
> }
> 
> So this returns "hello". I know add some debug:
> 
> def something() {
>   a()
>   println "done something"
> }
> 
> Does this break my function? Most likely.

(Continue reading)

Gavin Grover | 27 Jun 00:32
Favicon

Re: Re: [groovy-dev] optional returns

----- Original Message ----From: Andres Almiray <aalmiray@...>

> Given this observation we should consider adding optional returns to all
> blocks don't you think? why if/else receive special treatment and leave the
> others in limbo? that means for/while/(switch?) should be enhanced too

I hope you will change 'switch' also.

For both 'if' and 'switch' statements, I've sometimes made the mistake of leaving out a required 'return'.
I've never made that mistake for 'for' and 'while' though.

Cheers, Gavin Grover
gvgrover@...
gavingrover.blogspot.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Alex Tkachman | 27 Jun 06:46

Re: Re: [groovy-dev] optional returns

Problem with switch is that sometimes you have break and sometimes not.

On Fri, Jun 27, 2008 at 2:34 AM, Gavin Grover <gvgrover@...> wrote:
> ----- Original Message ----From: Andres Almiray <aalmiray@...>
>
>> Given this observation we should consider adding optional returns to all
>> blocks don't you think? why if/else receive special treatment and leave the
>> others in limbo? that means for/while/(switch?) should be enhanced too
>
> I hope you will change 'switch' also.
>
> For both 'if' and 'switch' statements, I've sometimes made the mistake of leaving out a required
'return'. I've never made that mistake for 'for' and 'while' though.
>
> Cheers, Gavin Grover
> gvgrover@...
> gavingrover.blogspot.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
(Continue reading)

Robert Fischer | 27 Jun 06:59
Favicon
Gravatar

Re: [groovy-dev] optional returns

Why is that a problem?

~~ Robert.

Alex Tkachman wrote:
> Problem with switch is that sometimes you have break and sometimes not.
> 
> On Fri, Jun 27, 2008 at 2:34 AM, Gavin Grover <gvgrover@...> wrote:
>> ----- Original Message ----From: Andres Almiray <aalmiray@...>
>>
>>> Given this observation we should consider adding optional returns to all
>>> blocks don't you think? why if/else receive special treatment and leave the
>>> others in limbo? that means for/while/(switch?) should be enhanced too
>> I hope you will change 'switch' also.
>>
>> For both 'if' and 'switch' statements, I've sometimes made the mistake of leaving out a required
'return'. I've never made that mistake for 'for' and 'while' though.
>>
>> Cheers, Gavin Grover
>> gvgrover@...
>> gavingrover.blogspot.com
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
(Continue reading)


Gmane