From: Austin Ziegler <halostatue@...>
Date: 2005-08-11T03:48:28+09:00
Subject: Re: new block notation

On 8/10/05, Ben Giddings <bg-rubytalk@infofiend.com> wrote:
> I agree that the current syntax is really confusing. Since Ruby
> 2.0 has a new major version number, I think that fixing
> confusing/broken things should take precedence over
> backwards-compatibility. It's all up to Matz and what he finds
> least surprising, but to me the current syntax for arrays and
> blocks is too confusing. I would prefer it they were made
> unambiguous

> I'd vote for either getting rid of {} for blocks and only allowing
> 'do ... end'. That may be an unpopular suggestion, but I think it
> makes the most sense. It's already a little confusing that there
> are two equal, yet different ways of creating a block.

They aren't equal, though. There is a binding difference between
do..end and {}.

  foo bar { baz }     # same as: foo(bar { baz })
  foo bar do baz end  # same as: foo(bar) { baz }

The difference in binding *is* useful, I think, as it does allow for
cleaner poetry mode:

  task :tar do |t|
    # ...
  end

Whatever solution involving blocks would have to make this binding
difference easy and clean, the way that it is now.

> This leads to people having their own conventions, like using {}
> only when it's a one-line block, and do ... end when it's a
> multiline block; or using {} when it returns a value, but do ...
> end when it doesn't.

That's a convention only cared about when the binding difference
isn't needed.

> Whatever the resolution though, I would prefer to see a situation
> where only one of blocks and hashes used {}, despite the
> backwards-compatibility issues.

On that, I'd agree. I wasn't sold, originally on the idea of [:] as
a null hash, but I think I prefer it overall.

-austin
-- 
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca