Re: Groovy beta 10 released! (+JSR Early Access)

As Martin said; if you really wanna use the closures and to use the 
'align brace' style indentation, then you can just use parens

foo.bar(
{
    // closure
})

foo.bar(param1, param2,
{
    // closure
})

So we don't really need a continuation character per se.

The edge case is really, what should this mean...

foo.bar
{
   ///
}

Currently this is interpreted as a regular block and not a closure 
call. We could enforce a keyword on free standing blocks to avoid any 
ambiguity.

On 2 Mar 2005, at 07:58, Dierk Koenig wrote:

> to add to the list of possible options:
> * introduce a closure keyword (mike) or character (xavier)
> * introduce a block keyword (jochen?)
> * introduce a line continuation character (Antti)
> * use delimiters other than {} for closures
>   maybe "do .. end" or "{-; .. ;-}" or such
>
> I don't claim any of the above is good or even preferrable.
> It's merely to complete the list of options..
>
> cheers
> Mittie
>
>
>> -----Original Message-----
>> From: jastrachan@... [mailto:jastrachan@...]
>> Sent: Mittwoch, 2. Marz 2005 8:34
>> To: user@...
>> Subject: Re: [groovy-user] Groovy beta 10 released! (+JSR Early 
>> Access)
>>
>>
>>
>> On 1 Mar 2005, at 21:56, Chris Poirier wrote:
>>
>>> Hi James,
>>>
>>> On Tue, 1 Mar 2005 jastrachan@... wrote:
>>>
>>>> The reasoning behind this is that without this rules we cannot use 
>>>> the
>>>> concise syntax for passing closures around. e.g. adding a newline
>>>> before { changes this meaning
>>>
>>> Um *cough* bullshit *cough*.
>>
>> Huh?
>>
>>> This /absolutely/ should have been fixed by the new grammar.  I mean,
>>> it
>>> was one of the core things needing fixing.  I, for one, won't be 
>>> using
>>> Groovy if it wants to dictate my brace style.  { on the same line 
>>> makes
>>> it much easier to drop braces by accident, and harder to verify at a
>>> glance that they are correct -- something I experienced often enough
>>> while working on the Groovy codebase.
>>
>> The issue is between passing closures into methods; or having blocks.
>>
>> foo.bar(2) { ... } // closure passing
>>
>> // regular method call with a separate block? Or same thing again with
>> a different layout?
>> foo.bar(2)
>> {
>> 	....
>> }
>>
>>
>> So far in Groovy we've always said that the only way of using the
>> closure passing syntax above is if the { is on the same line as the
>> method invocation itself.
>>
>> Currently the parser handles any kind of whitespace layout for
>> if/for/while you like - but we figured it might be good to gently
>> encourage folks to use a consistent { placement policy to avoid
>> confusion; so we generate a warning (actually currently we don't
>> display it :).
>>
>> Our options really are
>>
>> * keep doing what we're doing; handle any indentation on if/for/while
>> but generate a warning (which could be turned on/off) but still 
>> require
>> the { on the same line for closure calls
>> * disallow free standing blocks (which could also confuse and has
>> issues in the grammar, e.g. with labels)
>> * let users use any indentation policy they wish and possible let them
>> get confused with the above example - i.e. restricting the { placement
>> rule to only closure invocations
>> * force that every single statement absolutely must end with a 
>> semicolon
>>
>> Currently the first choice, the one we've implemented pretty much from
>> day one, is the one that feels most groovy. Which would you rather
>> Chris?
>>
>> James
>> -------
>> http://radio.weblogs.com/0112098/
>>
>
>

James
-------
http://radio.weblogs.com/0112098/