Re: semenatics of if/unless/while statement modifiers

Mathieu Bouchard wrote:

>On Wed, 23 Nov 2005, Stefan Kaes wrote:
>
>  
>
>>Mathieu Bouchard wrote:
>>    
>>
>>>An old RCR of mine proposed making "end" implicit just before a closing
>>>parens. It was rejected in little time. 
>>>      
>>>
>>Rightly so.
>>    
>>
>
>Why? it would've gotten rid of superfluous keywords.
>
>  
>
Yes, it would have gotten rid of closing "end" before closing ")". But I 
think it would have been difficult to read, because in Ruby you would 
always look out for the closing end after seeing an opening if. And for 
cases like

  a = (if b<7 then x else y) + expr

you can always use

  a = (b < 7 ? x : y) + expr

which has even less keywords :-)

>>But what kind of answer is this? You don't like the way things are now so go
>>take a hike?
>>    
>>
>
>Well, I was mistaken on what you call superfluous. I don't have *your* 
>definition of superfluous though.
>  
>
"then" and "else" and "end" or not necessary for

   if joins  = options[:joins]  then sql << " #{joins}"  end
   if limits = options[:limits] then sql << " #{limits}" end

as this could be written

  sql << " #{joins}"      if joins = options[:joins]
  sql << " #{limits}"     if limits = options[:limits]

if these forms were equivalent. By I have learned that

  joins  = options[:joins]    and   sql << " #{joins}"
  limits = options[:limits]   and   sql << " #{limits}"

works. But for me this is not the preferred way to write it, as it puts 
the emphasis on the assignments, whereas the if modifier version 
emphasizes the concatenation.

-- stefan