I just stumbled across an intresting problem with passing two hashes
to a method -- I was trying to pass inline hashes and ruby
interpretted them as blocks.  (Makes sense looking back).

start_form_tag :action => 'blah', :class => 'css1'

This call was putting both values into the first parameter of the
method (a hash), and none in the second one.  So I altered it:

start_form_tag {:action => 'blah'}, {:class => 'css1'}

Which of course ruby thinks the {} are blocks and pukes.

To explicitly tell ruby they are hashes, I had to wrap them with ().

start_form_tag ({:action => 'blah'}), ({:class => 'css1'})

Which seems awkward, as most languages use the {} syntax for inline hashes.

Since blocks can be do ... end or {}, I'd suggest we do something
similar to the string parsing way:  blocks declared with {} must be of
the form #{}.  This would clear up the hash/block problem, as well as
make hashes look more like other languages. So:


"1234".each #{ |c| puts c }

(or something to that effect)

This would make sense to me, as the in-string replacement:

num_of_chars = 37
puts "here's #{num_of_chars} chars to print"

seems to naturally flow as though the string object is passing control
to the expression within #{}, just like a block would.

I'm definitely a ruby newbie, but it would be much more obvious to me
this was a block vs. hash problem had that syntax been in place.

Any thoughts?


-- 
Brock Weaver