Phrogz
9/23/2007 3:18:00 AM
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.