On Mar 27, 10:39 am, "Rick DeNatale" <rick.denat... / gmail.com> wrote:
> On 3/27/07, David A. Black <dbl... / wobblini.net> wrote:

> >   true if a = 1              # no error
> >   b = 1; p b if a = 1     # no error
>
> True of course.
>
> What's interesting is that the if a=1 doesn't create the variable,
> since it does have to be executed first.
>
> I wouldn't recommend actually writing code like this, but it does seem
> a bit inconsitent.
>
> A quirk of the ruby parser? eval?

I'm too lazy to look it up, but this has been discussed on the ML
several times before. (I personally posted about it early in my Ruby
career and discussed it then.)

It's a quirk of the parser, which sees variable assignments in top-
down byte order of the source file, not post-parsed execution order.
I've frequently wished that it would work for cases where you want to
cache and test the return value of a method before performing a simple
action on it.

To be clear:

  # Works just fine
  if foo=bar() && !foo.nil?
    p foo.jim
  end

  # Doesn't parse/compile/whatever, though the
  # end call sequence should be the same.
  p foo.jim if foo=bar() && !foo.nil?