On Monday 20 June 2005 10:21, Nikolai Weibull wrote:
> Jason Foreman wrote:
> 
> > Even though it turns out there is no performance benefit to 1 == x
> > over x == 1, I find it desirable to write the former anyway.  If you
> > accidentally write x = 1 instead of x == 1, it can take a long time to
> > figure out your bug.  But if you write 1 = x instead of 1 == x, you
> > get a syntax error, and can immediately correct the mistake.
> 
> % ruby
> if x = 1; end
> -:1: warning: found = in conditional, should be ==
> 
> So please don't write your code as if it was 1980 and you were using a C
> compiler,

def retrieve_good_status_val
  :good_status
end

def retrieve_bad_status_val
  :bad_status
end

def get_status(good, bad)
  if rand > 0.2
    good
  else
    bad
  end
end

good_status = retrieve_good_status_val
bad_status = retrieve_bad_status_val
while good_status = get_status(good_status, bad_status)
  puts "Still good"
  sleep 0.1
end
puts "Bad status"

Ruby can get the simple cases like 'if x = 1' but it can't get all the 
variations.

At first, it might look ugly to have the un-assignable operand first, but 
you get used to it quickly, and a bit of ugliness is a small price to pay 
for more robust programs.

I write for C compilers all the time, but when I write Ruby there are still 
a lot of things I keep, even with its smarter interpreter.  In the end, I 
think using '=' as the assignment operator and '==' as the comparison 
operator is bad human-interface design.  What do you call that key?  
"equals", not "assigns" or something, but it's hardly a flaw unique to 
Ruby.  :)

Ben