On Sep 22, 4:32 pm, "Just Another Victim of the Ambient Morality"
<ihates... / hotmail.com> wrote:
>     I just wrote some code that shouldn't have worked, in my estimation, but
> it did, anyway.  While this was a pleasant surprise, I prefer to understand
> why things don't work than to wonder why they did work...
>
>     What was happening is this situation, here:
>
> if false
>     variable = true
> end
>
> if variable
>     #do something
> end
>
>     To my surprise, this is okay!  Even though the code in the first
> if-clause  doesn't get run, the variable in the clause gets created,
> anyway...
>     Now, I'm pretty sure this is expected behaviour.  What I'm wondering is
> how people feel about this.  This behaviour makes me feel uneasy.  If I'm
> using a variable that hasn't been deliberately created then I'd rather have
> the interpreter complain that I haven't created the variable, as planned,
> than to be confused as to why my variable is nil.
>     I'm very interested to hear other opinions on the subect.  Anyone care
> to comment?
>     Thank you...

I understand the behavior, and I've learned to live with it. But (as
I've noted on numerous occassions) I really don't like the reverse
side effect, that you can't write:
  p foo if foo=true
even though you can write:
  if foo=true then p foo; end

That two statements that are semantically identical should result in
different behavior when foo has not previously been assigned a value
is an unfortunate side effect/tradeoff of the implementation details
and choices.

I accept it in the same way I accept that arrays and hashes have, in
some cases, traded purity for speed. It ain't perfect, but it's what
we got.