jastrachan | 2 Mar 08:34 2005

Re: 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*.


> 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?

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